Hm... no... you don't have to commit it to the DB. BUT. You must be able to 
handle converting the uncommitted object to/from a string representation.
There are a variety of ways to do that, but it's worth noting that the default 
value encoders for the hibernate module do not handle un-persisted entities 
(don't know if you're using hibernate or not, but... sounds like it).

Robert

On Jul 12, 2011, at 7/124:08 PM , Ray Nicholus wrote:

> Nevermind, I'm ditching ajaxformloop - too many shortcomings/problems.  This
> component is not useful for my situation, and I would not consider my
> situation to be unusual at all.  Instead, I will opt to use a normal loop
> and create my own remove & add links/buttons.  It seems, for one, the
> ajaxformloops addRow event requires the server side to create a new row and
> commit it to the DB, which is a bit difficult to do before obtaining input
> from the user regarding the values of the form elements in the row.
> 
> On Tue, Jul 12, 2011 at 3:22 PM, Ray Nicholus <rnicho...@widen.com> wrote:
> 
>> In my ajaxformloop, I specify an clientId for each of my selects.  I am
>> working around an issue/shortcoming in Tapesty regarding zone updates in a
>> form loop.  To do this, I must be able to specify the IDs of my form
>> elements.  For one particular element, in each row of the form loop, I
>> specify a clientId which is unique.  However, when I add a row to the form,
>> tapestry appends something to the ID of this newly create element.  How can
>> I stop tapestry from doing this?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to