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> 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… J
>
>
>
> -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?
>
>
>