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]
