tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Piterman <mpla...@vollbio.de>
Subject Re: Deferred listeners -- backward incompatibility
Date Wed, 08 Jun 2005 12:48:08 GMT
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


Mime
View raw message