Richard,
Do you mean completely stateless relative to the HTTP session?
Yeah, unfortunately that is the case. I wish persistent properties was an option, but it isn't. :-\
Make a serializable class that represents the data the user is editing.
Create a property of the type the user is editing.
Set the initial value of the property to a new instance.
Make a hidden field that has a value of the property.
Attach all the form components to field of the object being edited.
Ah, yes. I'm doing something similar, tho I'm not binding the entire object to a hidden input field. This is where I'm probably going wrong.
I'll give your suggestions a try. Thanks!
e.
On May 18, 2005, at 4:38 PM, Hensley, Richard wrote:
Eric,
Do you mean completely stateless relative to the HTTP session? If this is
true, you are going to have to squirrel you data away on hidden fields in
your form.
I would do the following:
Make a serializable class that represents the data the user is editing.
Create a property of the type the user is editing.
Set the initial value of the property to a new instance.
Make a hidden field that has a value of the property.
Attach all the form components to field of the object being edited.
What tapestry will do is "squeeze" your object out to the html form when
your form is rendered to the browser. When the form is sumbitted, tapestry
will unsqueeze your object from the hidden field back into your property.
This should
allow you to track the users actions and render an appropriate form as
needed, and each form displayed in a browser has it's own "state".
Also, remember to set all the @Form and @xxxLink components to stateful="false".
Richard
-----Original Message----- From: Eric Schneider [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 18, 2005 12:16 PM To: Tapestry users Subject: dynamic forms that are stateless
Hi,
I have a requirement that I'm stumbling on. I have an editor page that needs to be completely stateless containing no persistent properties. Users must be able to open this page in multiple browsers windows, switching back and forth and performing updates.
This is no problem if there are a fixed amount of form elements. When the user clicks save, I instantiate the bean in pageBeginRender () so it can successfully take the values from the form.
Where it gets awkward is when you have a dynamic number form elements. (i.e. - a customer has 0-many shipping addresses). I have to re-inflate that list of shipping addresses before values are set to the beans within the lists. Unfortunately, there really isn't a good way to tell how many shipping address there are, aside from putting this count in a hidden form input (which is too late anyway). Has anyone geared up something like this?
I hope I'm explaining this well enough. Any suggestions would be greatly appreciated.
Thanks, e.
--------------------------------------------------------------------- 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]
