Yup. But see:
http://tapestry.apache.org/current/tapestry-core/ref/org/apache/tapestry5/corelib/components/AjaxFormLoop.html In particular, the encoder parameter: encoder ValueEncoder Required, NOT Allow Null prop Required parameter used to convert server-side objects (provided from the source) into client-side ids and back. A default encoder may be calculated from the type of property bound to the value parameter. When you return the object that represents the new row, AjaxFormLoop is going to attempt to convert that into a string representation for storage on the client. At submission time, it will attempt to "rehydrate" the object from the string. This ensures that the form fields update the correct object. If you aren't supplying a custom value encoder, then tapestry is providing one for you. If you are using hibernate, then the provided value encoder will throw an exception trying to encode an un-persisted object. So you can do exactly what you proposed, just make sure to override the default value encoder with a custom implementation. It could be a really simple implementation that just returns the string representation of the object's index in your list of objects. Robert On Jul 12, 2011, at 7/124:36 PM , Ray Nicholus wrote: > Can't I simply maintain a list of the persisted objects server side (the > source for the ajaxformloop), add a new object to the list in my onAddRow > handler, and simply save the non-persisted objects on form submit? > > On Tue, Jul 12, 2011 at 4:19 PM, Robert Zeigler <robert.zeig...@roxanemy.com >> wrote: > >> 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
