You are right in every point. more comments inline...
2005/11/22, Simon Kitching <[EMAIL PROTECTED]>: > Hi Mathias, > > Are you able to find time to check the info below, and answer the > question? Once that is done I can commit this new javadoc for the > UIData component. > > Thanks, Simon > > Simon Kitching wrote: > > Thanks Mathias. > > > > I now realise that (just like an InputText component will re-fetch its > > bound value before rendering) the UIData needs to re-fetch its DataModel > > object before rendering. And that when the datamodel object is reloaded > > the rowState really needs to be recomputed too, as the DataModel may > > have more elements, less elements, or reordered elements. > > > > This is clearly inconvenient for people who want to set properties on > > the table's child components earlier in the processing, and those people > > can now set preserveRowState to true if they really need to do this. > > However the price they pay is that they must not ever change the order > > of objects in the DataModel. you can use a valuebinding for preserveRowState which returns false if the datamodel has structurally changed or returns true if there are no changes. > > > > In the case of controlling the "rendered" attribute for a particular > > component in a particular row (Grant Smith's case) it would presumably > > be better to ensure the child components have a value-binding which > > calculates the rendered attribute on demand rather than try to set > > rendered state in row components from some action listener method. > > > > Have I got the above right? yes, using the rendered attribute is better for this use case > > > > Another question: I must be dense, but what's the reason that a UIData > > has a *map* of DataModel objects, keyed by the id of the UIData's parent > > component? Is this some special code to handle the case where a UIData > > component is "reparented"? yes, this map is used to map the right datamodel for nested uidata components. -- Mathias
