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" <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
