dev@javaserverfaces.java.net

Re: Components opting into attributesThatAreSet feature

From: Mark Collette <mark.collette_at_icesoft.com>
Date: Wed, 04 Feb 2009 16:40:58 -0700

This task has languished on our end because the scope of necessary
changes, to every single component's state saving, both in Mojarra and
in our suite, is a little too large. Hopefully a simpler approach might
be sufficient. I was wondering if it would be possible to just set a
context-param, that would globally enable use of attributesThatAreSet.
Applications could turn it on if the components they used would benefit
from it, and could turn it off if the state savings cost was too great.
Regardless of the context-param, the standard components would behave as
they already do. And in fact, if the context-param was true, it would
run ever so slightly faster, since it wouldn't have to do the string
test on the class name.


public abstract class UIComponent implements StateHolder {
    // Old way
    List<String> getAttributesThatAreSet(boolean create) {
        String name = this.getClass().getName();
        if (name != null && name.startsWith(OPTIMIZED_PACKAGE)) {
            if (create && attributesThatAreSet == null) {
                attributesThatAreSet = new ArrayList<String>(6);
            }
        }
        return attributesThatAreSet;
    }


    // New way
    private static boolean ALLOW_ALL_USE_ATTRIBUTES_THAT_ARE_SET = ...;

    List<String> getAttributesThatAreSet(boolean create) {
        if (create && attributesThatAreSet == null) {
            String name;
            if ( ALLOW_ALL_USE_ATTRIBUTES_THAT_ARE_SET ||
                 ((name = this.getClass().getName()) != null &&
name.startsWith(OPTIMIZED_PACKAGE)) {
                attributesThatAreSet = new ArrayList<String>(6);
            }
        }
        return attributesThatAreSet;
    }
}


Mark Collette
ICEsoft Technologies, Inc.
http://mark-icefaces-reflections.blogspot.com/


Ryan Lubke wrote:

> Mark Collette wrote:
>
>> Maybe the list could always track the set attributes, without
>> requiring the component be a stock JSF component? It would just be
>> the pass-through attribute rendering code that would impose the
>> limitation, that it would only use the list for stock JSF components?
>
> Would like to have a way to say what components so we don't force a
> state saving penalty on those component sets that don't depend on an
> implementation specific feature.
>
>>
>>
>> Mark Collette
>> ICEsoft Technologies, Inc.
>> http://mark-icefaces-reflections.blogspot.com/
>>
>>
>> Ryan Lubke wrote:
>>
>>> Mark Collette wrote:
>>>
>>>> Are there any limitations on adding public or protected methods
>>>> into UIComponent or UIComponentBase?
>>>
>>>
>>> Yes, it can't be done as the TCK signature tests would fail the build.
>>>
>>> Any changes to the API (public or protected) must be backed by the
>>> specification.
>>>
>>>>
>>>> Mark Collette
>>>> ICEsoft Technologies, Inc.
>>>> http://mark-icefaces-reflections.blogspot.com/
>>>>
>>>>
>>>> Ryan Lubke wrote:
>>>>
>>>>> Mark Collette wrote:
>>>>>
>>>>>> Is there any way for third party components to opt into making
>>>>>> use of the attributesThatAreSet feature?
>>>>>
>>>>>
>>>>>
>>>>> Probably not given the changes that were made for this feature in
>>>>> 1.2_10.
>>>>>
>>>>>> Or any plans to facilitate that, in the future?
>>>>>
>>>>>
>>>>>
>>>>> No plans at this point. Patches are welcome.
>>>>>
>>>>>>
>>>>>>
>>>>>> Mark Collette
>>>>>> ICEsoft Technologies, Inc.
>>>>>> http://mark-icefaces-reflections.blogspot.com/
>>>>>