It worked, but with defer=true. And yes, it is very clean... thanks for the tip!
-----Original Message----- From: Robert Zeigler [mailto:[EMAIL PROTECTED] Sent: terça-feira, 30 de agosto de 2005 19:19 To: Tapestry users Subject: Re: Strange behavior using listeners inside Foreach and For in Tapestry 4 Suggestion: add 'parameters="ognl:listItem" to the @Submit component. Change your listener definition to: public void removeItem(ListItem item) { getMyList().remove(item); } And keep "deferred" set to false. I haven't personally tried this, but if I recall correctly from earlier conversations, it should work. Very clean. :) Robert Denis Souza wrote: > Doesn't using defer="false" take me back to 3.0 behavior? > I tried it anyway just to see the result and I started getting a > java.util.ConcurrentModificationException whenever I clicked the "Remove" > button. > > IMHO I actually prefer that listeners are deferred since you don't need an > understanding of the rewind cycle to use them. Sure backwards compatibility > is an issue in some cases but even deferred listeners should be called in > the proper order so unless you have listeners that are necessarily depending > on the rewind cycle it shouldn't be a big problem. Of course, I might be > wrong. I'm not a Tapestry developer so I don't have a very broad under the > hood knowledge of Tapestry. > > Anyway, compatibility is not the problem in this case. I'd like to > understand what exactly the correct behavior is in Tapestry 4. Shouldn't a > deferred listener provide the "current" object for which it was activated? > If it should, then I'm guessing this is a bug, but if this is how it's > supposed to work I'll have to find another way to do what I want. > > > -----Original Message----- > From: Mind Bridge [mailto:[EMAIL PROTECTED] > Sent: terça-feira, 30 de agosto de 2005 16:28 > To: Tapestry users > Subject: Re: Strange behavior using listeners inside Foreach and For in > Tapestry 4 > > Try adding the following to your Submit component: > > defer="false" > > > I still think the current behaviour is very problematic and will cause > scores of problems exactly like this one. > > My suggestion on the -dev list was for 'listener' to have the 3.0 > behaviour (not to be defered) and add an 'action' parameter in addition > that will be a deferred listener. This is both backward compatible, > avoids potential problems, and gives you all necessary capabilities. > > > Denis Souza wrote: > > >>Consider this example: >> >> >> >>In my html template: >> >> >> >>. >> >> >> >><table> >> >>. >> >><tr jwcid="@Foreach" element="tr" source="ognl:myList" >>value="ognl:listItem"> >> >> <td> . </td> >> >> <td><input type="submit" jwcid="@Submit" >>listener="listener:removeItem" label="message:remove"/></td> >> >></tr> >> >></table> >> >>. >> >> >> >>In my java class I have a listener: >> >> >> >> public void removeItem() { >> >> getMyList().remove (getlistItem()); >> >> } >> >> >> >> >> >>So, to put it in English, I have a Foreach loop with a listener inside it >>that is supposed to remove an item from the list being displayed. >> >>Whenever I click one of the "remove" buttons my removeItem() method is >>called as it should, except that the item returned by "getListItem()" is >>always the last item in the list. It's never the item corresponding to the >>removed button I clicked, so I always end up removing the last item, no >>matter which button I click on. >> >>When I use "For" instead of "Foreach" not only does the "getListItem()" >>contain the last item in the list, but the list is intact when the page is >>reloaded (no items removed). >> >> >> >>To me this seems very strange since there is no other way of knowing which >>of the buttons was clicked. I don't know if I'm doing something wrong or if >>it's a bug. I understand that doing this was an issue in Tapestry 3 due to >>limitations during the rewind cycle and I had to use some special logic to >>do it. I thought in Tapestry 4 I could use this more direct approach but >>maybe I'm still missing something. >> >> >> >>I'm using Tapestry4-beta5 but I tried it with beta4 and got the same >>problem. >> >> >> >>Any ideas? >> >> >> >>Thanks >> >>Denis Souza >> >> >> >> >> >> > > > --------------------------------------------------------------------- > 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]
