Sorry, I figured it out. I haven't played with custom value encoders before, and that seems to have it's own set of new challenges for me.
On Tue, Jul 12, 2011 at 5:42 PM, Robert Zeigler <[email protected] > wrote: > Hard to say without seeing more code.... :) > > Robert > > On Jul 12, 2011, at 7/125:36 PM , Ray Nicholus wrote: > > > Thanks for this info. I did create a custom value encoder, and I > confirmed > > that the encoder is returning the correct object on toValue, but the > object > > is not updated with the current form values on submit. Am I missing > > something? > > > > On Tue, Jul 12, 2011 at 4:45 PM, Robert Zeigler < > [email protected] > >> wrote: > > > >> 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 < > >> [email protected] > >>>> 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 <[email protected]> > >>>> 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: [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] > >
