You can put that data which you want to display into session scope. Then you make use of that session variable to display in JSP.
Joined: Oct 12, 2000
using request scope is far preferred for data that doesn't need to be persisted between requests. Saves a lot of potentially unwanted sideeffects if you (accidentally or on purpose) use the same attribute name in different servlets and JSPs (like I do, as I have the core of a whole range of servlets in an abstract baseclass which sets quite a few things for all the derived classes (in fact it sets just about everything).
Originally posted by Stan James: Your redirect approach is used in what I call the "Post, Redirect, Get" pattern.
I use this almost constantly. I found that building sites around this behaviour takes a little more organisation, but many HTTP and browser problems disappear, and the page responsibilities are cleaner.
Your redirect approach is used in what I call the "Post, Redirect, Get" pattern.
I also use a similar pattern which differs just slightly:
Browser POSTs an input form to the server The server updates resources accordingly The server redirects to a controller (display support) servlet The browser GETs the controller servlet The server reads the resources needed to display the supported page The servlet forwards to the page The server returns the display page
All server 'hits' trigger a controller servlet -- each page has such a controller servlet to marshal any data that the page needs in order to render. The JSPs themselves are scriptless and use only the JSTL, EL and custom tags.
The point of these patterns is, of course, to not leave the POST that performed an operation 'dangling" on the browser. And David's point is a good one: this makes for a nice "orderly" application. [ January 14, 2005: Message edited by: Bear Bibeault ]
The drawback to this pattern is that you loose the first request.
How do you generally persist your data between requests? Do you always store in session or do you have to make an extra trip to the database?
Also, I've had the misfortune of having to deal with firewalls that don't allow redirects, but not recently. [ January 15, 2005: Message edited by: Ben Souther ]
Joined: Jan 29, 2003
Bear's extension with a controller is good. I was thinking of how my Wiki works and it's not quite like servlet / JSP.
After doing the update, the redirect has to contain enough key information to retrieve the right data. The POST for the update might contain a ton of data, but the redirect & get might only need a primary key as a URL parameter.
Oh, reading again that wasn't exactly your question. Yes, database storage has been my experience ... I've mostly done this when the POST will update something persistent.
BTW: Is "post, redirect, get" a common name for this? Is it like a Sun pattern or anything? I saw it in a magazine I think and have used it heavily ever since. [ January 15, 2005: Message edited by: Stan James ]
I do not apply this pattern to each and every operation. It is mostly applied to operations where, in order to display the results, a new trip to the server is required regardless of whether a forward or rediect would be used, or cases where 'replaying' the operation via a refresh would have detrimental consequences.There seems to be no physical force in the universe stronger than the urge for a user to click on that blasted refresh button.
An example that pops to my head from something I was working on the other day: a page shows a summary list of records from the db. The list is paged and allows the user to select records for deletion. After clicking the Delete button and executing the delete on the back end, a new database fetch for the page is required to get the list of records for the current 'page'. So the fact that a redirect occured to 'clear' the delete post off the page introduces only minimal operational overhead.