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]
