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 Thu, 03 Dec 2009 17:29:15 GMT
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