Lots of good stuff here! I guess my next project will have to be building a proof of concept for a way of handling the cycle issues. I like the thought of entirely skipping initialization on rewind, but so far this has given me a lot of headache because of nullpointers, empty collections not populated the way I excepted, and so forth...
This will be a lot easier to see if I remove all the clutter of a real-world example, and create a simple test page containing what I need to test this, if I find out something interesting, I will post the entire code in this thread. Thanks Inge On 2/15/06, Shawn Church <[EMAIL PROTECTED]> wrote: > > I've been there; it's always the little foxes... I am honestly not sure > whether I've ever tried exactly this scenario, but I might try and > reproduce it myself. I almost always need (or think I will sometime > need) multiple values to live together, so I usually create a bean > contained in a Collection of some sort. In that case, the @For value is > the bean, and the @TextField input value is a bean property, so there is > no conflict when it comes to getting/setting. > > If I have a chance tomorrow, I'll try and test this myself. It looks > like OGNL should have handled your initial attempt, but you still would > have needed the hidden vals. There was an OGNL bug "Fixed bug with not > calling conversion on setting value in array" fixed in 2.6.6, so you > might see which version you are using. I may be out in left field here > though. > > Shawn > > Todd O'Bryan wrote: > > I just didn't realize that (a) if I used something as a source in a > > @For I also needed to put it in a hidden field or make it persistent, > > (b) using the value="..." idiom in a @For doesn't update the source, > > at least with arrays. > > > > I think I would have figured out either of those pretty quickly. With > > both together, I ate literally hours over the last week or so. > > > > Todd > > > > On Feb 14, 2006, at 10:28 PM, Shawn Church wrote: > > > >> Todd, > >> > >> For me, either carefully-controlled session-persisted properties or > >> hidden form values have worked best. ListEdit might have helped you > >> in this case, but I've always found it to be pretty cumbersome, and > >> in the end all it really does is take care of setting up the hidden > >> fields for you. > >> > >> Shawn > >> > >> Todd O'Bryan wrote: > >>> > >>> On Feb 14, 2006, at 8:19 PM, Shawn Church wrote: > >>>> > >>>> Typically, pageBeginRender is invoked to initialize the page from > >>>> properties which (by this time) have already been set either by a > >>>> calling page, by a previous render, or by external page > >>>> initialization (by implementing IExternalPage). After page > >>>> rendering is complete, the rendered response is sent to the > >>>> client. The rewind phase is only invoked if a form is submitted. > >>>> In this case, the form's listener method is invoked (where you can > >>>> do whatever you like with the submitted form values), after which > >>>> pageBeginRender will again be invoked to render the page. > >>>> > >>>> Tapestry makes all of what you are trying to do very simple, but it > >>>> is important to understand exactly how it works. Tapestry in > >>>> Action covers all of this for Tapestry 3, and Kent Tong's book is a > >>>> tremendous resource for Tapestry 4. > >>> > >>> There is a gotcha that I just spent the last week or so being very > >>> annoyed by (I'm still in Tapestry 3.0.3). > >>> > >>> I had a String[] of values. I was populating the array in > >>> pageBeginRender() and then passing the values so gotten to the next > >>> page in the form's listener. > >>> > >>> I tried > >>> > >>> <span jwcid="@base:For" source="ognl:vals" value="ognl:val"> > >>> <input type="text" jwcid="@TextField" value="ognl:val" /> > >>> </span> > >>> > >>> Unfortunately, vals[0]-vals[n] were not getting updated...they were > >>> exactly what they used to be. So I tried updating the array directly > >>> > >>> <span jwcid="@base:For" source="ognl:vals" index="ognl:i"> > >>> <input type="text" jwcid="@TextField" value="ognl:vals[i]" /> > >>> </span> > >>> > >>> This seemed to update the array correctly, but my handle to the > >>> array became null and any calls to getVals()[0] in the listener > >>> returned an NullPointerException. Now, vals was not a persistent > >>> property, so it was getting lost. I could either make it persistent > >>> (back button nightmares) or the following, which finally worked: > >>> > >>> <input type="hidden" jwcid="@Hidden" value="ognl:vals"> > >>> <span jwcid="@base:For" source="ognl:vals" index="ognl:i"> > >>> <input type="text" jwcid="@TextField" value="ognl:vals[i]" /> > >>> </span> > >>> > >>> Now I could access the array using getVals() in the listener method > >>> and it contained the updated values. > >>> > >>> Did I do something wrong or is this just way more convoluted than it > >>> should be? Or would ListEdit have saved me some trouble? > >>> > >>> Todd > >>> > >>> --------------------------------------------------------------------- > >>> 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] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
