You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Shane Petroff <sh...@mayet.ca> on 2008/10/06 23:39:34 UTC

Re: [jira] Commented: (TRINIDAD-1226) CoreShowDetails doesn't function when created programatically

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