Simon.
I just passed this along to the EG.
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Jan 15, 2009, at 8:48 AM, "Simon Lessard" <simon.lessard.
[email protected]> wrote:
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
