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

[Blake Sullivan]

  +1 for Andy's proposal.

-- Blake

On 8/18/10 2:53 AM, Martin Marinschek wrote:
> +1 for Andy's combined proposal.
>
> best regards,
>
> Martin
>
> On 8/17/10, Andy Schwartz<andy.schwartz at oracle.com>  wrote:
>> 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
>>
>>
>