You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Simon Lessard <si...@gmail.com> on 2009/01/15 01:33:25 UTC
[JSF 2.0] UIComponent.getCurrentComponent behavior
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
Re: [JSF 2.0] UIComponent.getCurrentComponent behavior
Posted by Simon Lessard <si...@gmail.com>.
Hi Kito,
I could have done that too, I just wanted to get the general input from
everyone to see if anyone could think of counter arguments... Oh well, no
harm done anyway, except looking like if I'm snubbing the EG ;)
Regards,
~ Simon
On Thu, Jan 15, 2009 at 10:34 AM, Kito Mann <ki...@virtua.com> wrote:
> 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" <si...@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 < <ki...@virtua.com>
> 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.jsfcentral.com
>> <http://www.Virtua.com>http://www.Virtua.com
>>
>>
>> On Jan 14, 2009, at 6:33 PM, "Simon Lessard" <<s...@gmail.com>
>> 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
>>
>>
>
Re: [JSF 2.0] UIComponent.getCurrentComponent behavior
Posted by Kito Mann <ki...@virtua.com>.
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 <ki...@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
>
Re: [JSF 2.0] UIComponent.getCurrentComponent behavior
Posted by Simon Lessard <si...@gmail.com>.
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 <ki...@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" <si...@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
>
>
Re: [JSF 2.0] UIComponent.getCurrentComponent behavior
Posted by Kito Mann <ki...@virtua.com>.
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