• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

servlet -> JSP: make a new request?

 
Trailboss
Posts: 23778
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When doing a forward to a jsp, a request and a response must be sent. I have been recycling the request that my servlet received, but now I'm thinking that I should create a fresh request. After all, the parameters in the request were meant for the servlet, not for the JSP.

Is this what the big frameworks do?
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, the most prevalent modern pattern is for the servlet to perform its processing, tack any data that needs to passed to the JSP onto the request as scoped attributes and to forward to the JSP where the scoped variables are referenced using the EL/JSTL.

However, if the servlet receiving a form submission is a post that performs an action that shouldn't be repeated on the event of a refresh, it's common for the "action" servlet to initiate a new request (via a redirect) to another "view prep" servlet that does the prep for the JSP page which then forwards to the JSP.
[ January 13, 2006: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
P.S. This latter technique is sometimes called the PRG Pattern (post-redirect-get) and was written up in this article. I don't agree with all the assertions of the linked article, but it describes the pattern fairly well. It could do with an update, imo.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some more thoughts:

If you are moving towards JSP scriptless pages, and I see no reason that anyone using JSP 2.0 should not be, the Model 2 pattern where a "view prep" servlet controller handles data marshalling for the page is a very important concept.

Usually the "view prep" (I gotta come up with a better term for this) servlet/controller/action (whatever you wanna call it) is accessed with a GET. So a refresh will simply bring up the same view time and time again.

The other "type" of servlet/controller/action is an "action" servlet that performs some non-idempotent processing. This servlet is usually the target of a form submission via a post.

So frequently the chain of events might be:

1) Form on page is submitted to "action" servlet.

2) "Action" servlet preforms non-idempotent processing

3) Upon success (failure scenarios are another issue) redirects to the "view prep" servlet for the page that will show the results of the processing. This results in a GET for that servlet.

4) The "view prep" servlet obtains whatever it needs for the view and tacks it onto the request in EL-friendly scoped variables and forwards to the JSP.

5) The scriptless JSP uses the EL, JSTL and any custom actions (tags) to display the data.
[ January 13, 2006: Message edited by: Bear Bibeault ]
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yet more:

If the "action" servlet is idempotent (causes no state change), then the middle redirect is not necessary to "break" the request. In such cases, it's ok to forward from the "action" servlet to the "view prep" servlet. You may still want to redirect though in order to "convert" a POST to a GET. In any case, I always still segregate the "action" code from the "view prep" code.

All too commonly I see schizophrenic servlets that first perform processing, then do the view prep all in the same unit. This makes it difficult to reuse either the "action" code or the "prep" code elsewhere in the app. After all, in any non-trivial app there's bound to be more than one way to get to a page.

It's just another good application of "separation of concerns".
[ January 13, 2006: Message edited by: Bear Bibeault ]
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:
If the "action" servlet is idempotent (causes no state change), then the middle redirect is not necessary to "break" the request. In such cases, it's ok to forward from the "action" servlet to the "view prep" servlet.


On idempotent requests, you don't need an "action" servlet. You can point it straight to the "view prep" servlet.

Originally posted by Bear Bibeault:
You may still want to redirect though in order to "convert" a POST to a GET. In any case, I always still segregate the "action" code from the "view prep" code.


But you shouldn't use POST on idempotent requests anyway, unless perhaps you're submitting DNA mappings for a medical app or something else with ridiculously huge parameter values that won't fit in a GET.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marc Peabody:

On idempotent requests, you don't need an "action" servlet. You can point it straight to the "view prep" servlet.



Not always. There are many categories of actions that cause no state change. Firing off e-mail messages is one off the top of my head. It has nothing to do with "view prep" and should be it's own unit. I see no reason to bundle action code into view prep code in such a case.

Originally posted by Marc Peabody:

But you shouldn't use POST on idempotent requests anyway, unless perhaps you're submitting DNA mappings for a medical app or something else with ridiculously huge parameter values that won't fit in a GET.



It doesn't take much data to go beyond the limits of a GET. Mail message bodies, to use the same example as above. I usually use POST on form submissions to "action" servlets regardless of whether that action is going to cause a state change or not. It might violate the sensibilities of "HTTP purists", but within the realm of the web app it has its own satisfying consistency. (And keeps submitted data off the URL, which I like).
[ January 13, 2006: Message edited by: Bear Bibeault ]
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:

Not always. There are many categories of actions that cause no state change. Firing off e-mail messages is one off the top of my head. It has nothing to do with "view prep" and should be it's own unit. I see no reason to bundle action code into view prep code in such a case.


I agree to not bundle it. But doesn't sending an email change the state of someone's email Inbox?

Ok, I'm probably stretching the definition to fit my concept of idempotency. I think of non-idempotent requests as those that directly perform a unit of work (the work is usually a change to the server but, as in your example, not always).

I do agree that your email scenario deserves a separate "action" servlet but I don't agree that such a request is idempotent. In the absence of a redirect, clicking Refresh multiple times would cause the "unit of work" to repeat and flood someone's Inbox!

Originally posted by Bear Bibeault:

It doesn't take much data to go beyond the limits of a GET. Mail message bodies, to use the same example as above. I usually use POST on form submissions to "action" servlets regardless of whether that action is going to cause a state change or not. It might violate the sensibilities of "HTTP purists", but within the realm of the web app it has its own satisfying consistency. (And keeps submitted data off the URL, which I like).



What about search functionality? Using POST for that would prevent browser bookmarking and cause strange effects when selecting Refresh from the search results screen or navigating back to a past search results.

As far as mail message bodies go, I think such requests aren't idempotent anyway. See my "unit of work" rambling above.

I'm sure many, if not most, developers would disagree with me on this as I've never seen anyone else state these views on idempotency. I hope you're finding this discussion fun and interesting rather than annoying, by the way.

Sorry for the tangent to your question, Paul. I think Bear did cover the whole topic pretty thoroughly. Darn good job, too.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marc Peabody:

But doesn't sending an email change the state of someone's email Inbox?



True, but I wouldn't consider that part of the application's model.

Originally posted by Marc Peabody:

In the absence of a redirect, clicking Refresh multiple times would cause the "unit of work" to repeat and flood someone's Inbox!



Good point. In such a case I would definitely do the redirect (in fact, I almost always do regardless -- I was merely pointing out an alternative).

Originally posted by Marc Peabody:

What about search functionality? Using POST for that would prevent browser bookmarking



Another good point. But I rarely worry about browser bookmarking for actions. They frequently don't make sense in the internals of a web application.

Originally posted by Marc Peabody:

and cause strange effects when selecting Refresh



Not leaving a dangling POST solves that problem. As I said, I almost always use the post-redirect-get pattern and don't leave POSTs lying around for the refresh to trip over.

Originally posted by Marc Peabody:

I hope you're finding this discussion fun and interesting rather than annoying, by the way.



Absolutely! I hope there's at least as much give-n-take discussion when my article on constants in scriptless pages comes out in the next JavaRanch Journal.
 
Marc Peabody
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bear Bibeault:
True, but I wouldn't consider that part of the application's model.


Wise man once say,
The Network is the Computer.™

Is not the Network also the Application?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic