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