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.
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?
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"?
Regards,
Simon
Mathias Brökelmann wrote:
the reason why I introduced this flag was a recent change to
t:datatable by martin who hard coded this to preserveRowState=true.
But it is not a solution for every one, since clearing the datamodel
cache and rowstate cache must be done together. If
preserveRowState=true is used only the datamodel cache is cleared
(which results in calling the getter method for the value of
t:datatable before rendering the response).
If the rowstate is not cleared it is possible to save unbounded values
to the rendering phase. But if the datamodel changes (like add, remove
or sort rows) it will not work since t:datatable do not know which
rowstate belongs to which row data object. The rowstates are
identified only by the row index (current clientId of t:datatable is
used internally) not by row data.
The rowstate and the datamodel must be held during decode, validate,
update and invoke application phases. before rendering the datatable
it is determined if an error in the previous phases happened. If that
is the case the rowstate and the datamodel cache is not cleared and
reused to show the error on the page with old content. If there is no
error the rowstate and datamodel cache is discarded.
2005/11/14, Grant Smith <[EMAIL PROTECTED]>:
I'm having problems with this too. In my application, I now have to
submit
twice before I see the changes effect the datatable, even though the
model
is updated correctly after the first submit. I presume it's work in
progress
:)
On 11/13/05, Simon Kitching <[EMAIL PROTECTED]> wrote:
Hi,
I see that recently some work has been done on implementing a
"preserveRowStates" flag for the dataTable component.
As is (now) documented, the ancestor UIData component uses the
"flyweight" pattern so that only one set of child objects is used to
represent the columns and their contents. As each row is selected via
setRowIndex, the component state is saved in _rowStates array, and the
components are reinitialised with the _rowStates entry appropriate for
the next row.
However unless preserveRowState is set (it is false by default), the
encodeBegin method discards all row state before rendering begins.
I'm puzzled by this. Why is the row state cleared?
And if row state is going to be ignored, what's the point of saving it
at all?
Regards,
Simon
--
Grant Smith
--
Mathias
