Yet another issue: syncValue in ajaxformloop is never called on form submit for rows that have been added after the form renders. Everything seems to work ok for original rows.
On Tue, Jul 12, 2011 at 6:01 PM, Ray Nicholus <rnicho...@widen.com> wrote: > 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 < > robert.zeig...@roxanemy.com> 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 < >> robert.zeig...@roxanemy.com >> >> 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 < >> >> 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 >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >
