You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Denis Souza <ds...@sti.com.br> on 2005/08/30 21:10:52 UTC
Strange behavior using listeners inside Foreach and For in Tapestry 4
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
Re: Strange behavior using listeners inside Foreach and For in Tapestry 4
Posted by Jesse Kuhnert <jk...@gmail.com>.
Ah ok..scratch my last reply :)
On 8/30/05, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> I could be wrong, but I think the For component does some special logic
> when doing loops, like the case where it is looping over things in the form.
> It should magically resolve the "current" object you are referencing when
> the form is submitted.
>
> Foreach does not do any of this special magic, so when your listener is
> invoked, there is no concept of a "current" object, as it was a direct
> invocation.
>
> Doesn't the For component work just as well in or outside of a Form?
>
> On 8/30/05, Denis Souza <ds...@sti.com.br> 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
> >
> >
> >
> >
> >
>
Re: Strange behavior using listeners inside Foreach and For in Tapestry 4
Posted by Jesse Kuhnert <jk...@gmail.com>.
I could be wrong, but I think the For component does some special logic when
doing loops, like the case where it is looping over things in the form. It
should magically resolve the "current" object you are referencing when the
form is submitted.
Foreach does not do any of this special magic, so when your listener is
invoked, there is no concept of a "current" object, as it was a direct
invocation.
Doesn't the For component work just as well in or outside of a Form?
On 8/30/05, Denis Souza <ds...@sti.com.br> 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
>
>
>
>
>
Re: Strange behavior using listeners inside Foreach and For in Tapestry 4
Posted by Howard Lewis Ship <hl...@gmail.com>.
On 8/30/05, Mind Bridge <mi...@yahoo.com> wrote:
> 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.
+1
Don't forget LinkSubmit, ImageSubmit and whatever WML uses.
>
>
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Strange behavior using listeners inside Foreach and For in Tapestry 4
Posted by Denis Souza <ds...@sti.com.br>.
It worked, but with defer=true.
And yes, it is very clean... thanks for the tip!
-----Original Message-----
From: Robert Zeigler [mailto:robertz@scazdl.org]
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:mindbridgeweb@yahoo.com]
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Strange behavior using listeners inside Foreach and For in Tapestry
4
Posted by Robert Zeigler <ro...@scazdl.org>.
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:mindbridgeweb@yahoo.com]
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Strange behavior using listeners inside Foreach and For in Tapestry 4
Posted by Denis Souza <ds...@sti.com.br>.
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:mindbridgeweb@yahoo.com]
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Strange behavior using listeners inside Foreach and For in Tapestry
4
Posted by Mind Bridge <mi...@yahoo.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org