You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Mind Bridge <mi...@yahoo.com> on 2005/06/08 12:47:58 UTC
Deferred listeners -- backward incompatibility
Hi,
I am finding out that deferring listeners is rather backward
incompatible -- a lot of the code that I am looking at is assuming that
the form is rewinding at the time of the listener invocation and
additional parameters to the Submits are needed to make things work
again. This is particularly true for components located in loops. What's
even worse -- the code may render okay, but generate an exception only
when a button/link is pressed.
In general, the combination listener/defer is slightly problematic, as
the context of the 'listener' parameter gets changed depending on the
value of 'defer'.
I would suggest the submit components instead to have two listener
parameters -- 'listener', as it is works now, and 'action' which is
deferred. If the deferred approach is needed, then 'action' is used instead:
<a jwcid="@Submit" action="handleSubmit">....</a>
This approach is fully backward compatible, and it is shorter as well.
Do you think it makes sense?
-mb
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Deferred listeners -- backward incompatibility
Posted by Ron Piterman <mp...@vollbio.de>.
I also can not think of a reason right now, but guessing that such a
usage is out there - if you keep deffered as boolean, and *do* need both
- how do you solve this?
What is the cost of letting "action" and "listener" stay separate?
1. the terminology difference is a nice one, and makes it quite clear,
whereas deffered... I'm not sure.
2. you gain flexibility, which alternativeley can only be gained by
using some hacks...
Cheers,
Ron
ציטוט Andreas Andreou:
> If I may say so,
> unless there's a case where you want a component to both fire
> a normal listener and a defered one (which i really doubt), I would
> prefer using the
> deferred boolean parameter (defaulting to false for backward
> compatibility). It's my guess
> that this way will be easier and more consistent for us (the users)
>
> Glen Stampoultzis wrote:
>
>>
>> What about a deferred boolean parameter. The default being false so
>> it matches existing behavior.
>>
>> Mind Bridge wrote:
>>
>>> Hi,
>>>
>>> I am finding out that deferring listeners is rather backward
>>> incompatible -- a lot of the code that I am looking at is assuming
>>> that the form is rewinding at the time of the listener invocation and
>>> additional parameters to the Submits are needed to make things work
>>> again. This is particularly true for components located in loops.
>>> What's even worse -- the code may render okay, but generate an
>>> exception only when a button/link is pressed.
>>>
>>> In general, the combination listener/defer is slightly problematic,
>>> as the context of the 'listener' parameter gets changed depending on
>>> the value of 'defer'.
>>>
>>> I would suggest the submit components instead to have two listener
>>> parameters -- 'listener', as it is works now, and 'action' which is
>>> deferred. If the deferred approach is needed, then 'action' is used
>>> instead:
>>>
>>> <a jwcid="@Submit" action="handleSubmit">....</a>
>>>
>>> This approach is fully backward compatible, and it is shorter as well.
>>>
>>> Do you think it makes sense?
>>>
>>> -mb
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Deferred listeners -- backward incompatibility
Posted by Andreas Andreou <an...@di.uoa.gr>.
If I may say so,
unless there's a case where you want a component to both fire
a normal listener and a defered one (which i really doubt), I would
prefer using the
deferred boolean parameter (defaulting to false for backward
compatibility). It's my guess
that this way will be easier and more consistent for us (the users)
Glen Stampoultzis wrote:
>
> What about a deferred boolean parameter. The default being false so
> it matches existing behavior.
>
> Mind Bridge wrote:
>
>> Hi,
>>
>> I am finding out that deferring listeners is rather backward
>> incompatible -- a lot of the code that I am looking at is assuming
>> that the form is rewinding at the time of the listener invocation and
>> additional parameters to the Submits are needed to make things work
>> again. This is particularly true for components located in loops.
>> What's even worse -- the code may render okay, but generate an
>> exception only when a button/link is pressed.
>>
>> In general, the combination listener/defer is slightly problematic,
>> as the context of the 'listener' parameter gets changed depending on
>> the value of 'defer'.
>>
>> I would suggest the submit components instead to have two listener
>> parameters -- 'listener', as it is works now, and 'action' which is
>> deferred. If the deferred approach is needed, then 'action' is used
>> instead:
>>
>> <a jwcid="@Submit" action="handleSubmit">....</a>
>>
>> This approach is fully backward compatible, and it is shorter as well.
>>
>> Do you think it makes sense?
>>
>> -mb
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Deferred listeners -- backward incompatibility
Posted by Mind Bridge <mi...@yahoo.com>.
At the moment there is a boolean 'defer' parameter in 4.0 that defaults
to true.
I do think making the listeners deferred in the typical case (without
the need for an additional parameter) is a good idea. What I am
proposing is a way to have the cake and eat it too -- the above aim is
achieved, but backward compatibility is preserved.
Glen Stampoultzis wrote:
>
> What about a deferred boolean parameter. The default being false so
> it matches existing behavior.
>
> Mind Bridge wrote:
>
>> Hi,
>>
>> I am finding out that deferring listeners is rather backward
>> incompatible -- a lot of the code that I am looking at is assuming
>> that the form is rewinding at the time of the listener invocation and
>> additional parameters to the Submits are needed to make things work
>> again. This is particularly true for components located in loops.
>> What's even worse -- the code may render okay, but generate an
>> exception only when a button/link is pressed.
>>
>> In general, the combination listener/defer is slightly problematic,
>> as the context of the 'listener' parameter gets changed depending on
>> the value of 'defer'.
>>
>> I would suggest the submit components instead to have two listener
>> parameters -- 'listener', as it is works now, and 'action' which is
>> deferred. If the deferred approach is needed, then 'action' is used
>> instead:
>>
>> <a jwcid="@Submit" action="handleSubmit">....</a>
>>
>> This approach is fully backward compatible, and it is shorter as well.
>>
>> Do you think it makes sense?
>>
>> -mb
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: Deferred listeners -- backward incompatibility
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
What about a deferred boolean parameter. The default being false so it
matches existing behavior.
Mind Bridge wrote:
> Hi,
>
> I am finding out that deferring listeners is rather backward
> incompatible -- a lot of the code that I am looking at is assuming
> that the form is rewinding at the time of the listener invocation and
> additional parameters to the Submits are needed to make things work
> again. This is particularly true for components located in loops.
> What's even worse -- the code may render okay, but generate an
> exception only when a button/link is pressed.
>
> In general, the combination listener/defer is slightly problematic, as
> the context of the 'listener' parameter gets changed depending on the
> value of 'defer'.
>
> I would suggest the submit components instead to have two listener
> parameters -- 'listener', as it is works now, and 'action' which is
> deferred. If the deferred approach is needed, then 'action' is used
> instead:
>
> <a jwcid="@Submit" action="handleSubmit">....</a>
>
> This approach is fully backward compatible, and it is shorter as well.
>
> Do you think it makes sense?
>
> -mb
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org