shale-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary%20VanMatre <gvanma...@comcast.net>
Subject Re: Clay state question
Date Sat, 21 Mar 2009 16:53:30 GMT
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@gmail.com> 
To: user@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? 

Thanks, 
Ryan 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message