Are you aware of Ozark?
https://ozark.java.net/
On Tue, Mar 8, 2016 at 6:41 PM, Trenton D. Adams <trenton.d.adams_at_gmail.com>
wrote:
> 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?
>
>