No, I had never heard of it until you brought it up. I'll have to take a
look at it.
Will Jersey be implementing?
On Tue, Mar 8, 2016 at 6:00 PM, Phillip Ross <phillip.w.g.ross_at_gmail.com>
wrote:
> 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?
>>
>>
>