Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of gcjmu-myfaces-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@myfaces.apache.org
From: Werner Punz <werpu@gmx.at>
Subject: Re: Super!
Date: Thu, 20 Oct 2005 11:30:54 +0200
Lines: 35
Message-ID: <dj7o4e$v1m$1@sea.gmane.org>
References: <5a99335f0510180823q1bfc5e2ahc15960158913a3bf@mail.gmail.com>
	 <9eb65db00510180856g4f3dc52al@mail.gmail.com>
	 <6dac79b90510181306l3b070258m48ebbd65d4994683@mail.gmail.com>
	 <9eb65db00510190104s1fc187bcw@mail.gmail.com>
 <6dac79b90510191607u49616261xdd4a6fc8f8a0a49a@mail.gmail.com>
 <4356EF1D.1010804@obsidium.com>
Reply-To: werpu@gmx.at
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
In-Reply-To: <4356EF1D.1010804@obsidium.com>
Sender: news <news@sea.gmane.org>

Simon Kitching wrote:
> I'm still on the JSF learning curve, but I believe we're talking here
> about saving the UIComponent tree state, and that that is done via a
> custom approach in JSF.
> 
> Firstly the JSF framework saves the classnames of the UIComponent object
> tree, so that it can build an identical tree (but of new UIComponent
> instances) when it needs to.
> 
> Then each UIComponent object in the tree has its "saveState" method
> called, which is expected to return an object array containing its
> state. The UIComponent doesn't use java serialization; components with
> no children typically just store the primitive values of its member
> fields into an object array. Note that saveState can't use normal
> serialization because the "component tree" has already been rebuilt by
> the framework and that the return value of saveState is used to
> *repopulate a particular UIComponent instance* (the one restoreState is
> called on) rather than creating a UIComponent tree as deserialisation
> would do.
> 
> I don't know why this custom approach was used.
> 
> If I'm on the wrong track, please let me know.
> 

Probably to reduce the amount of data, every component only stores the
data it really has to, the problem of this approach is a slightly
performance hit, especially if you are in a cluster environment, because
the serialisation is basically done twice, first
from the component tree into the session and then from the session to
whatever is used for clustering.
But given the speed I can see from a bunch of running JSF apps I have
this performance hit is pretty neglectable.
As usual the biggest bottleneck always is db access.