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" <[email protected]> To: [email protected] 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
