Mailing-List: contact commits-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Apache Wiki <wikidiffs@apache.org>
To: Apache Wiki <wikidiffs@apache.org>
Date: Fri, 04 Dec 2009 07:57:51 -0000
Message-ID: <20091204075751.9351.46241@eos.apache.org>
Subject: 
 =?utf-8?q?=5BMyfaces_Wiki=5D_Update_of_=22Trinidad=5FFacesBean=5Fand=5FPa?=
 =?utf-8?q?rtialStateSaving=22_by_MatthiasWessendorf?=

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for c=
hange notification.

The "Trinidad_FacesBean_and_PartialStateSaving" page has been changed by Ma=
tthiasWessendorf.
http://wiki.apache.org/myfaces/Trinidad_FacesBean_and_PartialStateSaving

--------------------------------------------------

New page:
The Trinidad mplementation of !FacesBean already supported partialStateSavi=
ng, and for Trinidad's JSF 2 offerings it's now a [[https://issues.apache.o=
rg/jira/browse/TRINIDAD-1630|PartialStateHolder ]]

One reason is !FacesBean uses propertyKeys, which allow additional informat=
ion like capabilities.

Beyond that Andy Schwartz had actually taken a look at this previously. Her=
e'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 solu=
tion.

Note that the compatibility issues (#1) mainly impact component/renderer au=
thors (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 ve=
ry efficient property lookups. Second, the Trinidad approach avoids overhea=
d involved in the JSF's attribute-property transparency mechanism. When usi=
ng the JSF implementation of UIComponent.getAttributes().get("foo"), the fo=
llowing 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 sub=
classing (ie. by overriding accessor methods). Trinidad sacrifices this fle=
xibility for performance. Attribute lookups are routed directly to the !Fac=
esBean without invoking component accessor methods.