myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabrielle Crawford <gabrielle.crawf...@oracle.com>
Subject Re: Trinidad and JSF 2.0
Date Fri, 04 Dec 2009 19:07:04 GMT
Hi,

Andy is at a conference, I can try to talk to him about this next week.

Thanks,

Gabrielle

Martin Koci wrote:
> Hi,
>
> regarding component.getAttributes() vs. bean.getProperty() performance:
>
> do you have info under which circumstances is that difference
> noticeable? I do some profiling on two apps: the first one is
> trinidad12/jsf12 based and the second is JSF2 based. In both cases I
> have same view but JSF2 based application uses UIComponent and newly
> developed renderers instead trinidad. For example: CoreInputText ->
> NewInputText and SimpleInputTextRenderer -> NewSimpleInputTextRenderer.
> Algorithm in new renderers is the same as in trinidad but uses
> getAttributes() directly.
>
> I didn't notice a performance regression but maybe I look at wrong
> places. Obviously it must cost something especially during render
> response. Test is done for very complex view, loading is simulated as
> 100 concurrently working users - but YourKitProfiler shows very similar
> results for render response phase. Memory profiling I didn't do yet.
>
>
> Thanks,
>
> Martin Kočí
>
> Gabrielle Crawford píše v Čt 03. 12. 2009 v 09:29 -0800:
>   
>> Hi,
>>
>> Our implementation of facesBean in 1.2 already supported 
>> partialStateSaving, and for JSF 2 it's now a partialStateHolder
>> https://issues.apache.org/jira/browse/TRINIDAD-1630
>>
>> One reason is FacesBean uses propertyKeys, which allow additional 
>> information like capabilities.
>>
>> Beyond that Andy Schwartz had actually taken a look at this previously. 
>> Here's what he found.
>>
>> In theory the ideal solution should be to remove FacesBean in favor of 
>> the new standard APIs. However, in practice, there are two issues:
>>
>>    1. We need to maintain backwards compatibility.
>>    2. Trinidad's FacesBean solution is more efficient than the standard 
>> solution.
>>
>> Note that the compatibility issues (#1) mainly impact component/renderer 
>> authors (not application developers), yet is still an important issue 
>> for us.
>>
>> Regarding efficiency (#2)... FacesBean has two benefits over the 
>> standard solution. First, FacesBean supports indexed property keys, 
>> allowing for very efficient property lookups. Second, the Trinidad 
>> approach avoids overhead involved in the JSF's attribute-property 
>> transparency mechanism. When using the RI's implementation of 
>> UIComponent.getAttributes().get("foo"), the following steps are performed:
>>
>>     * First, look up the attribute in the attribute map.
>>     * If not found, use reflection to call the property getter (eg. 
>> getFoo()) on the component instance.
>>     * The getter then performs yet another lookup on the StateHelper.
>>
>> This approach allows property look ups to be more easily customized via 
>> subclassing (ie. by overriding accessor methods). Trinidad sacrifices 
>> this flexibility for performance. Attribute lookups are routed directly 
>> to the FacesBean without invoking component accessor methods.
>>
>> Thanks,
>>
>> Gabrielle
>>
>>
>> Matthias Wessendorf wrote:
>>     
>>> quick comment...
>>>
>>> one reason to keep that structure is that the components (trinidad) offer
>>> more APIs and behavior.
>>>
>>> Also, not sure if we really want to go with JSF 2.0's partial state saving.
>>> Looks like FacesBean has still some advantages.
>>>
>>> Gabrielle, can you provide some data here ?
>>>
>>> -Matthias
>>>
>>> On Thu, Dec 3, 2009 at 11:20 AM, Jan-Kees van Andel
>>> <jankeesvanandel@gmail.com> wrote:
>>>   
>>>       
>>>> Hey,
>>>>
>>>> I'm just asking this out of curiosity, so no offense intended. ;-)
>>>>
>>>> I see a lot of JSF 2.0 related activity in Trinidad and I was
>>>> wondering, why not leverage the JSF 2.0 code in MyFaces Core?
>>>> Are there (legacy) reasons to keep the UIX classes and not replace
>>>> them (maybe partially) with their JSF 2.0 equivalents?
>>>>
>>>> I can imagine that interoperability with other libraries increases
>>>> when Trinidad builds on (or extends) the JSF 2.0 API.
>>>>
>>>> Regards,
>>>> Jan-Kees
>>>>
>>>>     
>>>>         
>>>
>>>   
>>>       
>
>
>   

Mime
View raw message