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