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 <[email protected]> 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" <[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]> > [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.jsfcentral.com >> <http://www.Virtua.com>http://www.Virtua.com >> >> >> On Jan 14, 2009, at 6:33 PM, "Simon Lessard" <<[email protected]> >> [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 >> >> >
