Re: [jsr-314-open-mirror] [jsr-314-open] Proposal [868-DropCURRENT_COMPONENT CURRENT_COMPOSITE_COMPONENT]

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