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

[Martin Marinschek]

+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
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces