myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kito Mann <kito.m...@virtua.com>
Subject Re: [JSF 2.0] UIComponent.getCurrentComponent behavior
Date Thu, 15 Jan 2009 15:34:55 GMT
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. 
3@gmail.com> 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 <kito.mann@virtua.com>  
> 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" <simon.lessard.3@gmail.com 
> > 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
>

Mime
View raw message