Re: Clay state question

Hi Ryan, 

The primary reason was to lock down what made up the sub component tree after it was built the first time. This
component builds all its children the first rendering. For state management reasons, you have to make
sure that the component has the same shape on postback. This is especially important when it is in a UIData
family of component where there is only one instance of the component and the model is enumerated
underneath. We would need to store the subtrees off in a private facet if we wanted to start supporting
polymorphic subtrees. The displayElementObject should be the same instance in memory that the
TemplateConfigBean uses. 

Are you guys still using Clay or are you starting to migrate to Facets? 

Gary 

----- Original Message ----- 
From: "Ryan Wynn" <ryan.m.wynn <at> gmail.com> 
To: user <at> shale.apache.org 
Sent: Monday, March 16, 2009 3:25:38 PM GMT -07:00 US/Canada Mountain 
Subject: Clay state question 

I noticed that the Clay component saves the displayElementObject state in 
saveState. It would seem to me that this would cause some unnecessary 
overhead in terms of space when using server side state management. Since 
the displayElement root is already being cached globally in the 
TemplateConfigBean, would it be a valid optimization to have the Clay 
component retrieve it from there instead of "caching" it as part of the 
component state? 

Is there any reason why this needs to be saved as component state?