An order contains and addressForm, login/register form, and a payment card form. These are all hand reusable bit n pieces that can be reused.
if you nest this in an orderForm, scope the order form to session you can copy the properties from the component forms
to the order form. No dirty php hidden form value hacks, and that sort of jazz.
AddressForm address = (AddressForm) form;
OrderForm order = (OrderForm) session.getAttribute("order");
order.setAddress(address);when the user reaches the end of the order process just.
session.setAttribute("order",null);
This way you can still rearrange things if/when required but also use the connivence of storing persistent stuff in session, (which I reiterate yet again is what sessions are for).
On 11 Feb 2004, at 23:13, Robert Nocera wrote:
Using the session is certainly a possibility, I for the most part, take the
opposite approach. Generally the only objects I store in the session are
objects that are going to be accessed throughout the entirety of the user's
access to the site, stuff like authentication information and role
information.
I usually will use hidden form fields to carry information from one page to
the next, but it's usually a small amount of information such as the keys
for objects that may be needed for a next page.
I also find that if the entire application is architected so that all the
information an action needs is in the request as parameters, it becomes
truly simplistic to rearrange the workflow or add links to existing pages in
places you might not have expected them originally because the call requires
nothing more than the correct request parameters.
-Rob
-----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 11, 2004 4:45 PM To: Struts Users Mailing List Subject: Re: [OT] - Request against Session
There was an interesting posting the other day on this, I tend to stick stuff in the session because I cant be arsed messing around. After things are working I then see whether i can move things out. There seems to be a lot on not storing stuff in the session i imagine because things can get kinda heavy but then this begs the question what are sessions for?
I think people become a bit paranoid about sessions because java is kinda heavy in this respect, and garbage collection has remained an issue since its beginnings. But IMO thats for the folks you build the JVM's to worry about.
If you want something to persist beyond the request then I suggest put it in the session. By the time you've messed around trying to avoid this you could have brought more hardware to deal with the problem.
I'd say same as wendy, although look back if anything breaks.
IMO storing values as hidden form values is ugly, I'd use it as a hack if using session breaks anything (which is doubtful) just set stuff to null when you're finished and hope the garbage collector comes along.
On 11 Feb 2004, at 22:01, Pani R wrote:
Thanks for the advice Wendy.
I may end up storing all the values in the Session. But, on the other side, how would I store it in the hidden form variable. I think if I store it in my hidden variable, then its available to me in the action class via getParameter() which will return me a String object against my User Defined Object. Is there any other way to do that?
Pani
--
--------- Original Message ---------
DATE: Wed, 11 Feb 2004 13:27:11 From: Wendy Smoak <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> Cc:
From: Pani R [mailto:[EMAIL PROTECTED] Now, when the un-logged user tries to register, where am I suppose to store the Registration Values, Session or Request? Which one will be the better approach and why?
I'm not entirely sure when the session officially gets created, I just
expect it to be there, and it always is. If you're going to need
something across requests, you can either jump through hoops and put
it
in hidden form elements, etc., or just stuff it in the session.
I tend to treate memory and disk space as infinite resources, which may not scale, but works for my purposes. My vote is to put your values in the session and don't look back. Others may disagree...
-- Wendy Smoak
Application Systems Analyst, Sr.
ASU IA Information Resources Management
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
____________________________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/ default.asp?SRC=lycos10
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
