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: [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]
