MVC Master Template feature

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MVC Master Template feature

Trenton D. Adams
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?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

phillip.w.g.ross
Are you aware of Ozark?  https://ozark.java.net/

On Tue, Mar 8, 2016 at 6:41 PM, Trenton D. Adams <[hidden email]> 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?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Trenton D. Adams
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 <[hidden email]> wrote:
Are you aware of Ozark?  https://ozark.java.net/

On Tue, Mar 8, 2016 at 6:41 PM, Trenton D. Adams <[hidden email]> 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?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

phillip.w.g.ross
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 <[hidden email]> 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 <[hidden email]> wrote:
Are you aware of Ozark?  https://ozark.java.net/

On Tue, Mar 8, 2016 at 6:41 PM, Trenton D. Adams <[hidden email]> 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?




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Trenton D. Adams
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Are you aware of Ozark?  https://ozark.java.net/

On Tue, Mar 8, 2016 at 6:41 PM, Trenton D. Adams <[hidden email]> 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?





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Markus Karg-2-3
In reply to this post by Trenton D. Adams

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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Trenton D. Adams
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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Markus Karg-2-3

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Trenton D. Adams
Yes, now that I know about JSR 371, I totally agree, it is only related to that spec.  My initial comments were about Jersey, because I was unaware of JSR 371, and Jersey's MVC feature is simple, so I was investigating using it.

On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <[hidden email]> wrote:

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Lenny Primak
Sounds like you want to be using MVC with Facelets engine and use the layout component .
See this as an example:

On Mar 10, 2016, at 3:02 AM, Trenton D. Adams <[hidden email]> wrote:

Yes, now that I know about JSR 371, I totally agree, it is only related to that spec.  My initial comments were about Jersey, because I was unaware of JSR 371, and Jersey's MVC feature is simple, so I was investigating using it.

On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <[hidden email]> wrote:

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Trenton D. Adams
Ahh, interesting.  I'll check that out, thanks.  And, according to the JSR, facelets is supported.

On Thu, Mar 10, 2016 at 8:28 AM, Lenny Primak <[hidden email]> wrote:
Sounds like you want to be using MVC with Facelets engine and use the layout component .
See this as an example:

On Mar 10, 2016, at 3:02 AM, Trenton D. Adams <[hidden email]> wrote:

Yes, now that I know about JSR 371, I totally agree, it is only related to that spec.  My initial comments were about Jersey, because I was unaware of JSR 371, and Jersey's MVC feature is simple, so I was investigating using it.

On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <[hidden email]> wrote:

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Markus Karg-2-3

Yes, Facelets and JSP is mandatory with each MVC-compliant container, but there even is a simple SPI to add custom rendering engines. MVC is actually pretty neatly done! J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Freitag, 11. März 2016 06:01
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

Ahh, interesting.  I'll check that out, thanks.  And, according to the JSR, facelets is supported.

 

On Thu, Mar 10, 2016 at 8:28 AM, Lenny Primak <[hidden email]> wrote:

Sounds like you want to be using MVC with Facelets engine and use the layout component .

See this as an example:

 

On Mar 10, 2016, at 3:02 AM, Trenton D. Adams <[hidden email]> wrote:

 

Yes, now that I know about JSR 371, I totally agree, it is only related to that spec.  My initial comments were about Jersey, because I was unaware of JSR 371, and Jersey's MVC feature is simple, so I was investigating using it.

 

On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <[hidden email]> wrote:

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 

 

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Trenton D. Adams
I'm a bit confused on the facelets stuff.  Is facelets still a thing, or is it now JSF 2?  Cause as far as I've seen, there is no facelets JSR, but there is a JSF 2 JSR.  So, it would seem weird to implement a JSR dependent on a non-JSR technology.

On Fri, Mar 11, 2016 at 12:21 AM, Markus Karg <[hidden email]> wrote:

Yes, Facelets and JSP is mandatory with each MVC-compliant container, but there even is a simple SPI to add custom rendering engines. MVC is actually pretty neatly done! J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Freitag, 11. März 2016 06:01


An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

Ahh, interesting.  I'll check that out, thanks.  And, according to the JSR, facelets is supported.

 

On Thu, Mar 10, 2016 at 8:28 AM, Lenny Primak <[hidden email]> wrote:

Sounds like you want to be using MVC with Facelets engine and use the layout component .

See this as an example:

 

On Mar 10, 2016, at 3:02 AM, Trenton D. Adams <[hidden email]> wrote:

 

Yes, now that I know about JSR 371, I totally agree, it is only related to that spec.  My initial comments were about Jersey, because I was unaware of JSR 371, and Jersey's MVC feature is simple, so I was investigating using it.

 

On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <[hidden email]> wrote:

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 

 

 

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MVC Master Template feature

Markus Karg-2-3

Facelets has no standalone specification (so far), it is part of the JSF specification, but MVC enforces each MVC compliant container to provide support for Facelets – even if that container will not support JSF itself. You can simply rely on Facelets to be there. So Facelets is not non-JSR, it is simply covered by the JSF-JSR.

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Freitag, 11. März 2016 08:31
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

I'm a bit confused on the facelets stuff.  Is facelets still a thing, or is it now JSF 2?  Cause as far as I've seen, there is no facelets JSR, but there is a JSF 2 JSR.  So, it would seem weird to implement a JSR dependent on a non-JSR technology.

 

On Fri, Mar 11, 2016 at 12:21 AM, Markus Karg <[hidden email]> wrote:

Yes, Facelets and JSP is mandatory with each MVC-compliant container, but there even is a simple SPI to add custom rendering engines. MVC is actually pretty neatly done! J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Freitag, 11. März 2016 06:01


An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

Ahh, interesting.  I'll check that out, thanks.  And, according to the JSR, facelets is supported.

 

On Thu, Mar 10, 2016 at 8:28 AM, Lenny Primak <[hidden email]> wrote:

Sounds like you want to be using MVC with Facelets engine and use the layout component .

See this as an example:

 

On Mar 10, 2016, at 3:02 AM, Trenton D. Adams <[hidden email]> wrote:

 

Yes, now that I know about JSR 371, I totally agree, it is only related to that spec.  My initial comments were about Jersey, because I was unaware of JSR 371, and Jersey's MVC feature is simple, so I was investigating using it.

 

On Thu, Mar 10, 2016 at 12:58 AM, Markus Karg <[hidden email]> wrote:

Trenton,

 

if I understand your issue correctly, it really is an MVC-only issue and has nothing to do with Jersey or JAX-RS. So I think the best place to suggest this feature is either the Ozark team or the JSR371 expert group. I think you could also ask Christian Kaltepoth and Ivar Grimstad directly – I met them yesterday and they seem to be open for good ideas around MVC API. J

 

-Markus

 

Von: Trenton D. Adams [mailto:[hidden email]]
Gesendet: Donnerstag, 10. März 2016 08:53
An: [hidden email]
Betreff: [Jersey] Re: MVC Master Template feature

 

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 <[hidden email]> 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:[hidden email]]
Gesendet: Mittwoch, 9. März 2016 00:42
An: use
[hidden email]
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?

 

 

 

 

 

 

Loading...