wood burning stoves 2.0*
The moose likes JSP and the fly likes servlet -> JSP:  make a new request? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "servlet -> JSP:  make a new request?" Watch "servlet -> JSP:  make a new request?" New topic
Author

servlet -> JSP: make a new request?

paul wheaton
Trailboss

Joined: Dec 14, 1998
Posts: 20542
    ∞

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?


permaculture Wood Burning Stoves 2.0 - 4-DVD set
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

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 ]

[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

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 ]
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

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.


A good workman is known by his tools.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

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
Sheriff

Joined: Feb 05, 2003
Posts: 4727

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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

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
Sheriff

Joined: Feb 05, 2003
Posts: 4727

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?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: servlet -> JSP: make a new request?