users@jersey.java.net

[Jersey] Re: MVC Master Template feature

From: Trenton D. Adams <trenton.d.adams_at_gmail.com>
Date: Fri, 11 Mar 2016 00:31:24 -0700

I'm a bit confused on the facelets stuff. Is facelets still a thing, or is
it now JSF 2? Cause as far as I've seen, there is no facelets JSR, but
there is a JSF 2 JSR. So, it would seem weird to implement a JSR dependent
on a non-JSR technology.

On Fri, Mar 11, 2016 at 12:21 AM, Markus Karg <karg_at_quipsy.de> wrote:

> Yes, Facelets and JSP is mandatory with each MVC-compliant container, but
> there even is a simple SPI to add custom rendering engines. MVC is actually
> pretty neatly done! J
>
>
>
> -Markus
>
>
>
> *Von:* Trenton D. Adams [mailto:trenton.d.adams_at_gmail.com]
> *Gesendet:* Freitag, 11. März 2016 06:01
>
> *An:* users_at_jersey.java.net
> *Betreff:* [Jersey] Re: MVC Master Template feature
>
>
>
> Ahh, interesting. I'll check that out, thanks. And, according to the
> JSR, facelets is supported.
>
>
>
> On Thu, Mar 10, 2016 at 8:28 AM, Lenny Primak <lprimak_at_hope.nyc.ny.us>
> wrote:
>
> Sounds like you want to be using MVC with Facelets engine and use the
> layout component .
>
> See this as an example:
>
>
> http://www.andygibson.net/blog/article/how-to-do-10-common-tasks-in-jsf-2-0/
>
>
>
> On Mar 10, 2016, at 3:02 AM, Trenton D. Adams <trenton.d.adams_at_gmail.com>
> wrote:
>
>
>
> Yes, now that I know about JSR 371, I totally agree, it is only related to
> that spec. My initial comments were about Jersey, because I was unaware of
> JSR 371, and Jersey's MVC feature is simple, so I was investigating using
> it.
>
>
>
> On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <karg_at_quipsy.de> wrote:
>
> Trenton,
>
>
>
> if I understand your issue correctly, it really is an MVC-only issue and
> has nothing to do with Jersey or JAX-RS. So I think the best place to
> suggest this feature is either the Ozark team or the JSR371 expert group. I
> think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I
> met them yesterday and they seem to be open for good ideas around MVC API.
> J
>
>
>
> -Markus
>
>
>
> *Von:* Trenton D. Adams [mailto:trenton.d.adams_at_gmail.com]
> *Gesendet:* Donnerstag, 10. März 2016 08:53
> *An:* users_at_jersey.java.net
> *Betreff:* [Jersey] Re: MVC Master Template feature
>
>
>
> Hi Markus,
>
>
>
> Thanks for the response. I did read JSR 371. It was a really excellent
> read actually, and I was quite excited about this spec. I really liked the
> idea of of the @ReqirectScoped, as that one little thing saves a LOT in
> state management.
>
>
>
> It didn't seem to address the things I mention in my email though.
> Perhaps I didn't include some core thing in my explanation that made it
> unclear, so let me try from another angle.
>
>
>
> With most JSP MVC frameworks that I've seen, you need to have each jsp
> page, such as hello.jsp, include headers, footers, navigation, etc, in
> every file. But, the mechanism I've been using for years, makes that not
> necessary, and saves a lot on repetitive includes, as well as needing to
> change lots of files when the layout changes in some way that makes
> adjustments necessary.
>
>
>
> So, what would be nice for JSR 371, is to have your class annotated with
> something like @MasterView("index.jsp"). Then the MVC framework dispatches
> to index.jsp EVERY time. Then, when a controller returns "hello.jsp" for
> example, the MVC framework sets a request attribute of "view". Adopting my
> previous snippet (as a section of index.jsp), and changing the "model.page"
> to "view", we have...
>
>
>
> <!-- This is the content section of index.jsp, including individual content pages, if they were returned by the controller -->
>
> <*c**:when **test**="**${view* == *'/WEB-INF/jsp/test.jsp'**}**"*>
> <*jsp:include page="/WEB-INF/jsp/test.jsp"*/>
> </*c:when*>
> <*c:when test="${view* == *'/WEB-INF/jsp/testpath.jsp'**}"*>
>
> <*jsp:include page="/WEB-INF/jsp/testpath.jsp"*/>
> </*c:when*>
> <*c:when test="${view* == *'/WEB-INF/jsp/com/example/ApiKeys/main.jsp'**}"*>
>
> <*jsp:include page="/WEB-INF/jsp/com/example/ApiKeys/main.jsp"*/>
> </*c:when*>
>
> So essentially we have views that are returned by the controllers as content only views. The @MasterView(...) defines the actual main view. If no @MasterView is present, the MVC framework defaults to the view returned by the controller as being the master view with no content view request attribute defined.
>
> Does that make sense? Am I missing something, in terms of this maybe already being included? I've only read the spec once so far, so I could totally be missing something.
>
>
>
> On Thu, Mar 10, 2016 at 12:30 AM, Markus Karg <karg_at_quipsy.de> wrote:
>
> Trenton,
>
>
>
> there is currently a new specification under development (JSR 371,
> https://www.jcp.org/en/jsr/detail?id=371): “MVC 1.0”. It is targeting
> exactly what you want: Using JAX-RS as Controller for MVC, and lets you use
> ANY front-end technology for rendering (like JSP or Facelets for example).
> MVC 1 extends JAX-RS 2. Ozark is the Reference Implementation (RI) and
> AFAIK currently the only implementation. Ozark currently only runs ontop of
> Jersey, but this is only due to technical limitations which might be solved
> in future. We’re working on that at the moment… J
>
>
>
> -Markus
>
> (JAX-RS Expert Group Member)
>
>
>
> *Von:* Trenton D. Adams [mailto:trenton.d.adams_at_gmail.com]
> *Gesendet:* Mittwoch, 9. März 2016 00:42
> *An:* users_at_jersey.java.net
> *Betreff:* [Jersey] MVC Master Template feature
>
>
>
> Hi Guys,
>
>
>
> We've always used a very simple Command Pattern J2EE framework. But, I'm
> look at the various MVC frameworks out there, to see what might be the
> easiest to use, while being flexible enough to handle any need. Seeing
> that JAX-RS seems to allow virtually any type of HTTP handling, and it's
> very simple to use, I'm leaning towards using it's MVC framework.
>
>
>
> I'd like to add an MVC feature to Jersey, in a way that doesn't affect the
> current way that Jersey MVC is implemented; obviously we don't want to
> break existing systems. i.e. backwards compatible.
>
>
>
> PROBLEM
>
> Including JSP navigation, header, foot, and generally any *page* layout
> includes into every page is a lot of hassle. If you ever do a rebranding,
> you may (and frequently do) need to change those around. If on the other
> hand, ALL layout is done in a single JSP file, and that file does the
> including of all content related pages, there's only one single place to
> change the layout.
>
>
>
> POSSIBLE SOLUTION
>
> I'd like to have the concept of @MasterTemplate(name = "index.jsp"), where
> if that is present on the class, all @Template references get transformed
> into automatically setting the page field of the service, and
> "${model.page}" references refer to it. It would be assumed that any
> method using @Template would then need to return the service class, and
> that service class would need to implement a MasterTemplate interface
> perhaps, so that they all have the String getPage() method.
>
>
>
> Then, the master template file has includes like the following. As you
> can see, the caveat is that you do need to change this file every time you
> add content. But that's a very minor issue, considering the benefits.
> I've gone through rebrands doing it this way, a few times now. It use to
> be soooo painful, but now it's easy peasy lemon squeezy. If writing an
> application that needs to be extendable by clients, then creating a
> "content.jsp" that the client can overwrite to have their content pages
> included like we're doing below, is an easy way to make it so that they
> don't need to modify it.
>
> <*c**:when **test**="**${*model.page == *'/WEB-INF/jsp/test.jsp'**}**"*>
> <*jsp:include page="/WEB-INF/jsp/test.jsp"*/>
> </*c:when*>
> <*c:when test="${*model.page == *'/WEB-INF/jsp/testpath.jsp'**}"*>
> <*jsp:include page="/WEB-INF/jsp/testpath.jsp"*/>
> </*c:when*>
> <*c:when test="${*model.page == *'/WEB-INF/jsp/com/example/ApiKeys/main.jsp'**}"*>
> <*jsp:include page="/WEB-INF/jsp/com/example/ApiKeys/main.jsp"*/>
> </*c:when*>
>
> Thoughts?
>
>
>
> p.s.
>
> If this is a feature that Jersey developers don't want to include, is
> there a way I can implement such a thing without it being integrated into
> Jersey code?
>
>
>
>
>
>
>
>
>
>
>