Skip to main content

ui:repeat and its children state saving issue

2 replies [Last post]
kurtz_mr
Offline
Joined: 2011-02-03
Points: 0

I have experienced an annoying behavior of UIRepeat. Having something like this:

<ui:repeat value="#{myList}" var="myVar">

    &lt;ui:repeat value=&quot;#{myOtherList}&quot; var=&quot;myVar&quot;&gt;<br />
        &lt;h:inputText value=&quot;#{myVar.value}&quot;/&gt;<br />
  &lt;/ui:repeat&gt;<br />
&lt;/ui:repeat&gt;

Notice myVar is used for both external and nested ui:repeat. (This may seem like trivial to work around with unique var names. I use a custom dynamic include component though and I don't know in advance how many levels of ui:repeat will be there).
Now ui:repeat performs custom state management of editable values of its children. It is supposed to prevent loss between iterations of entered values which haven't been applied to the underlying model objects. In this case we will have a problem. When external ui:repeat tries to save the values of all children, h:inputText value will evaluate to myVar from external ui:repeat instead of the nested one. Here we will save the wrong value. But in my more complex case it generates PropertyNotFoundException.
Unfortunately there is no way of disabling this state saving. I believe tomahawk's t:dataList has it available as an optional feature. I don't really want to include tomahawk since I don't need anything else from there.
Now my question. Do I really need this children state management if I bind directly to my model? Is there anything I'm not seeing which makes it obligatory? I don't rely on JSF validations, so lost non-validating values are no issue. If not I will submit a feature request to introduce ui:repeat attribute preserveRowStates (same name as tomahawk). The default value would be true of course.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kurtz_mr
Offline
Joined: 2011-02-03
Points: 0

I have solved my problem.
My original use case was an include component evaluated in rendering phase - unline ui:include which has a TagHandler only. Also this component had to allow multiple nesting within ui:repeat and so on. The issue I have mentioned in my first post was causing some trouble with this. I got everything to work by using a slightly altered version of ui:repeat which among others does not descend into nested UIRepeat but saves its entire state instead.

kurtz_mr
Offline
Joined: 2011-02-03
Points: 0

double posted