I ran a few tests and was able to easily reproduce your original problem. I first tested as you did with an Array of Strings, and then with an ArrayList of Strings, and finally with an ArrayList of Integers. In none of these cases was I able to see my inputs reflected in the submitted (hidden) list of values in my form listener. I was also using ognl 2.6.7, so there is no issue there.
I think the main issue is the fact that Strings are immutable. Putting a String into a Java bean having normal accessors and mutators (getters and setters), everything works fine with one caveat. If you are using @base:For and you have a hidden field to store your list, you will need to specify formless="ognl:true" to prevent the original values from being retained. If you are using @Foreach, it will work without any issues. Sorry for the short response, but I have a meeting in a couple of minutes. Hopefully this clears things up a little. Shawn Quoting Shawn Church <[EMAIL PROTECTED]>: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
