Hi Matt,
I use and prefer #2 wherever I can. It gives me a lot of flexibility and I
can call my actions from wherever I want. Just have to remember the
parameters like calling methods/functions (old procedural code habits). Also
you get less problems when using the back/forward buttons. But the
disadvantage is that you cannot specify forwards in struts-config.xml. You
have to create ActionForwards in your actions and return them. Or is there
any other way?
BTW if you use DispatchActions with this technique its more fun.
But sometimes you _have_ to use #1 of course but not in the scenarios you
mentioned.
Affan
----- Original Message -----
From: "Kruse, Matt" <MKruse@aquent.com>
To: <struts-user@jakarta.apache.org>
Sent: Tuesday, April 08, 2003 1:06 AM
Subject: Add->Save->View: Internal or Browser Redirect?
> I'm seeking opinions from real world experience for the following
scenario:
>
> 1) User goes to an Add Record screen
> 2) Modifies form, clicks Save
> 3) Action class handles BO manipulation, then needs to send user back to
> view the record he just created
>
> Question: What is the best way to get the ID of the newly-created record
to
> the view screen?
>
> Two solutions:
> A) Internal Redirect
> 1) AddItem Action gets ID of new record
> 2) Sets ID in request attribute
> 3) Forwards to "Success" which maps to ViewItem
> 4) ViewItem checks req attributes for ID first, if not there, checks
req
> parameters
>
> ADVANTAGE: Single request. No need to create dynamic GET parameters.
>
> B) Browser Redirect
> 1) AddItem Action gets ID of new record
> 2) Forwards to "Success" which maps to browser redirect to ViewItem,
and
> adds parameter of "?ITEM_ID=1"
> 3) Browser sends another request to view, using item ID
>
> ADVANTAGE: ViewItem always has same interface, ie, getting ID from req
> parameters. Bookmarking of page works correctly. Reloading works
correctly.
> Avoids "Action Chaining".
>
>
> Which method have others used successfully? Is there any convincing reason
> to use one method over the other?
>
> Matt Kruse
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
|