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. ☺
-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<mailto: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… ☺
-Markus
(JAX-RS Expert Group Member)
Von: Trenton D. Adams [mailto:trenton.d.adams_at_gmail.com<mailto:trenton.d.adams_at_gmail.com>]
Gesendet: Mittwoch, 9. März 2016 00:42
An: users_at_jersey.java.net<mailto:rs_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?