On Mon, Aug 16, 2010 at 9:48 AM, Ed Burns <edward.burns(a)oracle.com <mailto:edward.burns@oracle.com>> wrote: >>>>> On Wed, 11 Aug 2010 11:46:21 -0400, Kito Mann <kito.mann(a)virtua.com <mailto:kito.mann@virtua.com>> said: KM> Couldn't you modify the map to return the constant values for the KM> proper keys? That way, they would be read-only values that don't KM> need to be stored, the Map just needs to know the keys. I'm sorry, I don't understand what you mean. Can you please restate it differently? Basically, what I'm saying is that we could change the Map implementation to simply delegate to UIComponent.getCurrentComponent() and UIComponent.getCurrentCompositeComponent() in the get() method whenever the key value is CURRENT_COMPONENT or CURRENT_COMPOSITE_COMPONENT. This way we'd save space but would maintain backwards compatibility without the switch. Ed -- | edward.burns(a)oracle.com <mailto:edward.burns@oracle.com> | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 02 work days until JSF 2.1 Milestone 2

Now it's me not to understand what you mean :) Did you mean to slow down implementing it, or the actual performance of the implementation?

Implementing it the way Kito suggests, will probably be faster then having to read a context-parameter, even if both solutions will have neglectable impact overall. I guess adding two static PropertyDescriptors (with appropriate read-methods) to the property descriptor map wouldn't add any noticeable overhead. Returning null for the write-method will also make them read-only as suggested (this probably should depend on a context-parameter, but would postpone the evaluation of it until a write call is made, which probably no one ever uses) Imre On 17.08.2010, at 05:06, Blake Sullivan wrote: > This would needlessly slow down the context attributes > implementation, which is also hammered on. > > -- Blake Sullivan > > On 8/16/10 9:10 AM, Kito Mann wrote: >> >> On Mon, Aug 16, 2010 at 9:48 AM, Ed Burns <edward.burns(a)oracle.com >> <mailto:edward.burns@oracle.com>> wrote: >> >> >>>>> On Wed, 11 Aug 2010 11:46:21 -0400, Kito Mann >> <kito.mann(a)virtua.com <mailto:kito.mann@virtua.com>> said: >> >> KM> Couldn't you modify the map to return the constant values >> for the >> KM> proper keys? That way, they would be read-only values that don't >> KM> need to be stored, the Map just needs to know the keys. >> >> I'm sorry, I don't understand what you mean. Can you please >> restate it >> differently? >> >> >> Basically, what I'm saying is that we could change the Map >> implementation to simply delegate to >> UIComponent.getCurrentComponent() and >> UIComponent.getCurrentCompositeComponent() in the get() method >> whenever the key value is CURRENT_COMPONENT or >> CURRENT_COMPOSITE_COMPONENT. This way we'd save space but would >> maintain backwards compatibility without the switch. >> >> >> Ed >> -- >> | edward.burns(a)oracle.com <mailto:edward.burns@oracle.com> | >> office: +1 407 458 0017 >> | homepage: | http://ridingthecrest.com/ >> | 02 work days until JSF 2.1 Milestone 2 >> >> >

On 8/17/10 4:32 PM, Blake Sullivan wrote: > > The actual performance of the implementation.  We've measured the > performance of the current implementation and the overhead is > non-negligible.  I agree that if the proposal is to reread the > context-parameter on each call, that would be far too expensive.  Faster, > if grosser implementations could involve storing a final boolean on the > UIComponent. How about we combine Ed and Kito's proposals? Ed: > Due to our iron-clad commitment to backwards compatibility, we keep the > public static final String constants, but alter the behavior, providing > a context-param to restore the old behavior. > > The constants will only be honored if the context param is set. > Kito: > Couldn't you modify the map to return the constant values for the proper > keys? That way, they would be read-only values that don't need to be > stored, the Map just needs to know the keys. So, the combined solution would be: By default these keys are not honored.  Applications that want to call: > FacesContext.getAttributes().get(UIComponent.CURRENT_COMPONENT) Instead of: > UIComponent.getCurrentComponent() (Why?) Can set a context parameter that forces the the FacesContext implementation to use a Map that specially handles get() calls for the old keys. For fun, in development project stage we can detect/warn about attempts to reference these attributes by key and recommend the type-safe alternatives. Andy