Mark Collette wrote:
> 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.
One problem I see with the suggestion is:
private static boolean ALLOW_ALL_USE_ATTRIBUTES_THAT_ARE_SET = ...;
If the class is shared across all webapps, then the value assigned there
is shared by all of them. I don't think that behavior is desirable. It
should
be per-webapp.
>
>
> 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/
>>>>>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>