2010/5/26 Martin Marinschek
<mmarinschek@apache.org>
>> well, you need to have all children constructed, when
>> markInitialState() is called on the table, right? Is that what it
>> boils down to?
>>
>
> When markInitialState() is called on the table, we need to save the state of
> all children
> inside the table component. Later, when UIData.setRowIndex is called we use
> that
> information to restore the initial state first of each component and then
> apply the delta.
>
> Right now, when markInitialState() is called on the table, all children
> inside the table has
> been already marked, so we need to call clearInitialState() on all children,
> then call saveState()
> to get the required information and then call again markInitialState().
>
> I tried to find an alternative to not traverse the tree calling
> markInitialState() as suggested,
> and use something different like a listener to PostAddToViewEvent, but I
> found that it will not
> work, because it is possible to create a tag that add some attached object
> to a component
> on this event (for example: t:autoScrollPage).
Andy, you are concerned about additional tree-traversals, right?
Yes. My test for this one is a variant of tomahawk datatable example:
<h:dataTable id="data" styleClass="standardTable"
headerClass="standardTable_Header" footerClass="standardTable_Header"
rowClasses="standardTable_Row1,standardTable_Row2"
columnClasses="standardTable_Column,standardTable_ColumnCentered,standardTable_Column"
var="country" value="#{countryList.countries}">
<h:column>
<f:facet name="header">
<h:outputText value="#{bundle['label_country_cities']}" />
</f:facet>
<h:dataTable id="cities" styleClass="standardTable_Column"
var="city" value="#{country.cities}">
<h:column>
<h:inputText id="city" value="#{city}" style="font-size: 11px" />
</h:column>
</h:dataTable>
</h:column>
</h:dataTable>
Note in this case, if we let the algorithm as is, markInitialState() for "cities" is called twice.
>> Do you have any ideas how we could do this better if we want to properly
>> implement partial state saving in tables?
I'll keep trying to find alternatives for this one.
best regards,
Leonardo Uribe
If not, I would like to add this approach to our 2.1 roadmap.
Should we open issues?