Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48EA8596.8020507@mayet.ca>
Date: Mon, 06 Oct 2008 16:39:34 -0500
From: Shane Petroff <shane@mayet.ca>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: dev@myfaces.apache.org
Subject: Re: [jira] Commented: (TRINIDAD-1226) CoreShowDetails doesn't
 function
 when created programatically
References: <1645726033.1221233384303.JavaMail.jira@brutus>
 <48CA96B9.7070006@mayet.ca>
In-Reply-To: <48CA96B9.7070006@mayet.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Shane Petroff wrote:
> Andrew Robinson (JIRA) wrote:
>> You are clearing the children component on every single get call.
> Every _set_, but regardless, I have to take a look to make sure I 
> haven't gotten my example out of synch with the real code.

Did the explanation below make sense to anyone? Given the choice of 
generating a single page via java code which is then re-built for each 
submission, vs 1K+ very similar pages vs 100+ large pages making 
judicious use of the rendered property, I chose the first option. The 2 
use cases also driving this decision were the need to navigate 
essentially randomly through the various details and the need to alter 
page contents without developer or designer intervention.

> That said, I do need to rebuild the entire page after submission 
> (hence the getChildren().clear()). This is a 'detail' page whose 
> content is not know at design time. There are thousands of possible 
> combinations of components which make up this page, and those 
> combinations change from time to time, so it is not reasonable to 
> develop a normal page per combination. As a user iterates through 
> objects (examining their details) the same page is reconstructed based 
> on metadata describing the particular instance they happen to be 
> looking at. User instances which are adjacent in the list which is 
> being traversed, can have radically different profiles, so I just 
> reconstruct the page.
>
>> I would suggest that you try to alter your code to make sure the 
>> component is only created once (use an attribute on the parent 
>> component).   
>
> I want to recreate components once per submission in this case.

I realize that this isn't a 'normal' approach, but I'm not sure how else 
I could have structured things. The only thing that seems to be 
'required' (found through experimentation, not spec) is that component 
id's need to be allocated in a deterministic way. The show detail seems 
not to like id's 'duplicated' in distinct naming containers, but it too 
behaves when names are deterministic and consistent. Am I going to be in 
trouble in the future with this approach?

-- 
Shane