Yeah for sure. I'm planning on running to work and printing out a copy of
the spec tomorrow.
Thanks for the heads up on that. Hopefully it takes into account the stuff
I've brought up here. As far as I've seen so far, that's the only
limitation with the Jersey MVC I've seen.
On Tue, Mar 8, 2016 at 7:56 PM, Phillip Ross <phillip.w.g.ross_at_gmail.com>
wrote:
> I'll let you do the deeper research for your own analysis, but I believe
> Ozark is built on top of Jersey. I believe it will be the reference
> implementation for the new MVC specifications in upcoming java enterprise
> (JEE) versions.
>
> On Tue, Mar 8, 2016 at 9:47 PM, Trenton D. Adams <
> trenton.d.adams_at_gmail.com> wrote:
>
>> 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?
>>>>
>>>>
>>>
>>
>