You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Eric Schneider <er...@centralparksoftware.com> on 2005/05/18 21:16:21 UTC
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: dynamic forms that are stateless
Posted by Eric Schneider <er...@centralparksoftware.com>.
Robert,
> Tell me, if all initialization is done in pageBeginRender, then
> how are the dynamic elements (lists, etc.) initialized in the first
> place?
The object is inflated and passed to the page via an action on
another page. For that first render, no initialization is required
in pageBeginRender.
So, after the page is rendered, it's stripped of its state and
returned to the page pool. It's the form submission part that's
jacking me all up.
> I suspect that you're also using
> cayenne...? If you are, watch out for null data contexts on
> re-serialization.
Bingo! Actually, I went with a struts style form bean thing. The
bean takes the values from the form and has convenience methods to
copy it's values to a DataObject.
So, for existing objects (ones committed to the db)....
- I re-inflate my DataObject from a key passed in a hidden input
- copy form bean values to it,
- validate,
- then commit
Clear as mud, huh? :-)
Eric
On May 18, 2005, at 10:31 PM, Robert Zeigler wrote:
> I think I'm understanding the issue better now. :)
> Tell me, if all initialization is done in pageBeginRender, then
> how are the dynamic elements (lists, etc.) initialized in the first
> place? You gave example of shipping addresses... how do you know how
> to initialize the shippingAddresses list to begin with? Is the
> composite
> object set in a listener method elsewhere? Or...?
> Richard's suggestion sounded fine. I suspect that you're also using
> cayenne...? If you are, watch out for null data contexts on
> re-serialization.
>
> Robert
>
> Eric Schneider wrote:
>
>> Robert,
>>
>>
>>> I'm curious as to how putting the count in a hidden is too late?
>>>
>>
>>
>> Maybe you can tell me? As far as I can tell, the composite object
>> (which holds all the form elements) is null when pageBeginRender() is
>> invoked. In other words, it has not taken any values from the form
>> yet. If I don't instantiate the object in pageBeginRender(), the
>> page
>> throws because it's attempting to set a value on a null object.
>>
>> I'm going to try Richard's suggestion. See if that gets me
>> somewhere.
>>
>> Thanks,
>> e.
>>
>> On May 18, 2005, at 5:00 PM, Robert Zeigler wrote:
>>
>>
>>> Eric Schneider wrote:
>>>
>>>
>>>> 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'm curious as to how putting the count in a hidden is too late?
>>> When
>>> the page is first rendered, do you have access to the size of the
>>> list
>>> before the loop? If so, couldn't you just put in the size of the
>>> list in
>>> a @Hidden (before the loop) and use a listener with the @Hidden to
>>> re-instantiate the list? I've used this strategy several times with
>>> success. But... maybe I'm missing something? :)
>>>
>>> Robert
>>>
>>>
>>>>
>>>> I hope I'm explaining this well enough. Any suggestions would be
>>>> greatly appreciated.
>>>>
>>>> Thanks,
>>>> e.
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: tapestry-user-
>>>> unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail: tapestry-user-
>>>> help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user-
>>> help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-
>> help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: dynamic forms that are stateless
Posted by Robert Zeigler <ro...@scazdl.org>.
I think I'm understanding the issue better now. :)
Tell me, if all initialization is done in pageBeginRender, then
how are the dynamic elements (lists, etc.) initialized in the first
place? You gave example of shipping addresses... how do you know how
to initialize the shippingAddresses list to begin with? Is the composite
object set in a listener method elsewhere? Or...?
Richard's suggestion sounded fine. I suspect that you're also using
cayenne...? If you are, watch out for null data contexts on
re-serialization.
Robert
Eric Schneider wrote:
> Robert,
>
>> I'm curious as to how putting the count in a hidden is too late?
>
>
> Maybe you can tell me? As far as I can tell, the composite object
> (which holds all the form elements) is null when pageBeginRender() is
> invoked. In other words, it has not taken any values from the form
> yet. If I don't instantiate the object in pageBeginRender(), the page
> throws because it's attempting to set a value on a null object.
>
> I'm going to try Richard's suggestion. See if that gets me somewhere.
>
> Thanks,
> e.
>
> On May 18, 2005, at 5:00 PM, Robert Zeigler wrote:
>
>> Eric Schneider wrote:
>>
>>> 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'm curious as to how putting the count in a hidden is too late? When
>> the page is first rendered, do you have access to the size of the list
>> before the loop? If so, couldn't you just put in the size of the list in
>> a @Hidden (before the loop) and use a listener with the @Hidden to
>> re-instantiate the list? I've used this strategy several times with
>> success. But... maybe I'm missing something? :)
>>
>> Robert
>>
>>>
>>> I hope I'm explaining this well enough. Any suggestions would be
>>> greatly appreciated.
>>>
>>> Thanks,
>>> e.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-user- help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: dynamic forms that are stateless
Posted by Eric Schneider <er...@centralparksoftware.com>.
Robert,
> I'm curious as to how putting the count in a hidden is too late?
Maybe you can tell me? As far as I can tell, the composite object
(which holds all the form elements) is null when pageBeginRender() is
invoked. In other words, it has not taken any values from the form
yet. If I don't instantiate the object in pageBeginRender(), the
page throws because it's attempting to set a value on a null object.
I'm going to try Richard's suggestion. See if that gets me somewhere.
Thanks,
e.
On May 18, 2005, at 5:00 PM, Robert Zeigler wrote:
> Eric Schneider wrote:
>
>> 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'm curious as to how putting the count in a hidden is too late? When
> the page is first rendered, do you have access to the size of the list
> before the loop? If so, couldn't you just put in the size of the
> list in
> a @Hidden (before the loop) and use a listener with the @Hidden to
> re-instantiate the list? I've used this strategy several times with
> success. But... maybe I'm missing something? :)
>
> Robert
>
>>
>> I hope I'm explaining this well enough. Any suggestions would be
>> greatly appreciated.
>>
>> Thanks,
>> e.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-
>> help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: dynamic forms that are stateless
Posted by Robert Zeigler <ro...@scazdl.org>.
Eric Schneider wrote:
> 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'm curious as to how putting the count in a hidden is too late? When
the page is first rendered, do you have access to the size of the list
before the loop? If so, couldn't you just put in the size of the list in
a @Hidden (before the loop) and use a listener with the @Hidden to
re-instantiate the list? I've used this strategy several times with
success. But... maybe I'm missing something? :)
Robert
>
> I hope I'm explaining this well enough. Any suggestions would be
> greatly appreciated.
>
> Thanks,
> e.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: dynamic forms that are stateless
Posted by Mind Bridge <mi...@yahoo.com>.
Hi,
Just curious, why is placing the info in a Hidden too late?
Also, do ListEdit or For (on www.t-deli.com) do what you want?
-mb
----- Original Message -----
From: "Eric Schneider" <er...@centralparksoftware.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, May 18, 2005 10:16 PM
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org