Hi<br><br>Yes, I know this too. In few words, all "transient" properties, that means, <br>all properties that are not stored in the state are not saved. There are very<br>few examples. To solve this one, there are multiple alternatives. I was thinking<br>
on extend StateHelper interface to add some methods like <br>putTransientProperty and getTransientProperty. Trinidad stores all properties<br>on the FacesBean object. <br><br>Anyway, I think an "mixed" solution could solve this problem: create an <br>
interface called RowStateTransientHolder, so only the components that <br>implements this type of attributes could have the chance to<br>save and restore its state.<br><br>But note in any case, it is necessary to do something like this to solve the<br>
use case described.<br><br>I didn't knew that localValueSet was a transient property too.<br><br>regards,<br><br>Leonardo Uribe<br><br><div class="gmail_quote">2010/3/19 Alexander Smirnov <span dir="ltr"><<a href="mailto:asmirnov@exadel.com">asmirnov@exadel.com</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I've thought about these problems for a long time too. Your proposal has<br>
a disadvantage because per-row state is quite different from the<br>
component state. Take a look for the UIInput implementation:<br>
localValueSet field is never saved in the state while it should be vary<br>
from row to row. The same thing happens to the UIForm.submitted<br>
attribute, that has been eventually added to the UIData spec instead of<br>
common solution, that would save/restore all local variables. My<br>
proposal was a separate RowStateHolder interface with<br>
save/restoreRowState methods there component developer can preserve<br>
internal variables. In the your stenario, there should be some flag that<br>
tells component to save all values, even these that are not supposed to<br>
be preserved between requests.<br>
<div><div></div><div class="h5"><br>
On 03/19/2010 10:27 AM, Leonardo Uribe wrote:<br>
> In short, this topic is an attempt to add full state to components<br>
> inside UIData. I'll do a brief resume, so people can understand this one<br>
> easily.<br>
><br>
> UIData uses the same component instances to render multiple rows.<br>
> Suppose this example:<br>
><br>
> <h:dataTable id="cities" var="city" value="#{country.cities}"><br>
> <h:column><br>
> <h:outputText value="#{city}" /><br>
> </h:column><br>
> </h:dataTable><br>
><br>
> In the component tree it is created this hierarchy:<br>
><br>
> HtmlDatatable<br>
> UIColumn<br>
> HtmlOutputText<br>
><br>
> If we have 10 cities, the same component is used over and over to render<br>
> all 10 cities. The reason to do that in this way is keep state as small<br>
> as possible.<br>
><br>
> Now let's suppose something like this:<br>
><br>
> <h:dataTable id="cities" var="city" value="#{country.cities}"><br>
> <h:column><br>
> <h:inputText value="#{city}" /><br>
> </h:column><br>
> </h:dataTable><br>
><br>
> It was changed the output component for an input one. If this table is<br>
> in a form and the values are submitted, the same component is used to<br>
> apply request values, validate and apply them to the model (update<br>
> process). To make this possible, UIData class has some code to preserve<br>
> this values between phases (using EditableValueHolder interface), so<br>
> when each phase is processed, all rows are traversed and you get the<br>
> expected behavior.<br>
><br>
> Now suppose something more complex: We have a code that use<br>
> invokeOnComponent to change the style of my inputText. In theory, only<br>
> one row should change. But in fact, all rows are rendered with the same<br>
> color. Why? because we use the same component to render all rows, and we<br>
> don't preserve the children component state between rows.<br>
><br>
> There is a lot of issues, questions, and side effects related to this<br>
> issue, but just to put some of them here:<br>
><br>
> TOMAHAWK-1062 InputTextArea doesn't work properly inside facet DetailStamp<br>
> TOMAHAWK-96 Data table Scroller not working the dataTable which was<br>
> actually contained in other DataTable<br>
> <a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153" target="_blank">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153</a><br>
> Problems with UIData state saving<br>
><br>
> Also, it is well know that one reason why people uses c:forEach in<br>
> facelets, is because this one create "full" components per each row. It<br>
> is very easy to find articles on internet.<br>
><br>
> Now, with jsf 2.0 we have partial state saving, so we have a chance to<br>
> fix this one once and for all. I tried fix this one per months (maybe<br>
> years!), but talking with Martin Marinschek on JSFDays, some ideas came<br>
> out and finally it was found a possibility to fix this one using the<br>
> existing api and with little changes on the spec.<br>
><br>
> The proposal is this:<br>
><br>
> 1. Do not call UIComponent.markInitialState() on<br>
> ComponentTagHandlerDelegate, as ComponentHandler javadoc says, instead<br>
> call it after PostAddToViewEvent are published on vdl.buildView(). We<br>
> need to call it from root to nodes, so the parent component is marked<br>
> first. I know the place where this call comes is from trinidad tag<br>
> handler, but this call needs to be fixed in a more predictable way.<br>
> 2. Use an attribute on facesContext to identify when the VDL is marking<br>
> the initial state (in myfaces there is already an attribute called<br>
> "org.apache.myfaces.MARK_INITIAL_STATE"). This is necessary to indicate<br>
> UIData instances that it is time to save the full state of all component<br>
> children,<br>
> 3. Allow UIData to hold a map where the key are client ids and the value<br>
> are the deltas of all components per row. This map should be saved and<br>
> restored.<br>
> 4. Change UIData.setRowIndex() to restore and save the component state.<br>
><br>
> I'll attach a patch on myfaces issue tracker with the algorithm proposed<br>
> (because it is based on myfaces codebase). It was tested and it works.<br>
> But note it is necessary to fix the javadoc for<br>
> UIData.markInitialState(), ComponentHandler and maybe vdl.buildView(),<br>
> so the intention is propose this change for jsf 2.0 rev A. Note this<br>
> works only with PSS enabled because without it we don't have a place to<br>
> notify UIData instances that it is necessary to get the full state.<br>
> Also, note this patch preserve backward compatibility, because the old<br>
> way to store/save is applied after the full state is restored.<br>
><br>
> Really, I have the strong temptation to apply some similar code on<br>
> myfaces UIRepeat component (because this class is private), but I prefer<br>
> first ask to EG to know what you guys think about it.<br>
><br>
> Suggestions are welcome,<br>
><br>
> regards,<br>
><br>
> Leonardo Uribe<br>
><br>
</div></div></blockquote></div><br>