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?
>>
>>
>>
>>
>>
>
>
>