You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mike Kienenberger <mk...@gmail.com> on 2009/12/16 14:43:24 UTC

Deprecating t:updateActionListener in 1.2, removing in 2.0?

Should we consider deprecating t:updateActionListener in 1.2 and
removing it in 2.0 now that f:setPropertyActionListener exists?

Perhaps for 1.2, we should consider making the tag an alias for
f:setPropertyActionListener component rather than a separate
component.

As far as I know, there is no intentional difference in behavior
between the tomahawk component and the core component.  I know for
facelets that f:setPropertyActionListener is facelets-aware and works
better for passing objects between template fragments.   I'm pretty
sure that you can change the underlying object using f:setPropertyAL
and have it reflected in the caller, but you cannot do so with
t:updateAL as this was why I ended up switching over all of my code a
few years back.

Re: Deprecating t:updateActionListener in 1.2, removing in 2.0?

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi

Since there is a lot of changes in jsf 2.0, we could remove or deprecate
from it, but we can't "redirect" t:updateActionListener to
f:setPropertyActionListener in 1.2, because different tag handler classes
implements it in ri and myfaces.

Maybe the same applies for other components in tomahawk that has
counterparts in myfaces commons library, and now are deprecated.

regards,

Leonardo Uribe

2009/12/16 Mike Kienenberger <mk...@gmail.com>

> Should we consider deprecating t:updateActionListener in 1.2 and
> removing it in 2.0 now that f:setPropertyActionListener exists?
>
> Perhaps for 1.2, we should consider making the tag an alias for
> f:setPropertyActionListener component rather than a separate
> component.
>
> As far as I know, there is no intentional difference in behavior
> between the tomahawk component and the core component.  I know for
> facelets that f:setPropertyActionListener is facelets-aware and works
> better for passing objects between template fragments.   I'm pretty
> sure that you can change the underlying object using f:setPropertyAL
> and have it reflected in the caller, but you cannot do so with
> t:updateAL as this was why I ended up switching over all of my code a
> few years back.
>