Hi Kito,
Yes, but it may also be a weakness in the spec. #{compositeComponent} is
resolved using UIComponent.getCurrentCompositeComponent (see section
5.6.2.1) and it would seem the resolver for #{component} is going to use
FacesContext.getCurrentInstance().getAttributes().get(UIComponent.CURRENT_COMPONENT_ATTRIBUTE)
while it should return UIComponent.getCurrentComponent imho. Anyway maybe I
should raise that directly on the EG as a public review comment.
Regards,
~ Simon
On Wed, Jan 14, 2009 at 9:45 PM, Kito Mann <[email protected]> wrote:
> Simon,
>
> If you were to take the Map approach, it wouldn't technically follow
> JavaDoc for the reason you state (other posible ELResolvers).
>
> Sent from my iPhone
> http://www.jsfcentral.com
> http://www.Virtua.com
>
>
> On Jan 14, 2009, at 6:33 PM, "Simon Lessard" <[email protected]>
> wrote:
>
> Hi all,
>
> The JavaDoc for UIComponent.getCurrentComponent says:
>
> "Return the UIComponent instance that is currently processing. This is
> equivalent to evaluating the EL expression "#{component}" and doing a
> getValue operation on the resultant ValueExpression. This method must
> return null if there is no currently processing UIComponent"
>
> So, my first implementation was to do just that, call the ELResolver to
> resolve #{component}. However, that processing is slower than simply
> evaluating the current component being processed which is stored in the Map
> attribute. The Map is already available to the class since UIComponent is in
> charge of pushing and popping the current component. The only drawback I
> would see to read directly from the Map is if the user add a new custom
> ELResolver for #{component} to do some funky things, then the
> getCurrentComponent would no longer catch that alteration.
>
>
> What do you think?
>
> ~ Simon
>
>
