UIRepeat issues

[michpetrov]

First of all we seem to be tracking two kinds of issues:

1. Components not keeping their state when the page is refreshed
   • although caused by the same thing I'd expect this is working as intended, and a panel losing its collapsed/expanded state doesn't look like a serious issue
2. State change events where the event doesn't retrieve the old value properly
   • this is certainly an issue

With rich:collapsiblePanel there is PanelToggleEvent - what I've found out is that the event is fired during Apply Request Values Phase (phase 2). But in case of pure JSF, e.g. h:selectOneListBox (which I used in the reproducer for #3452), the ValueChangeEvent is fired during Process Validations Phase (phase 3).

My setup is this:

<h:panelGroup id="message" layout="block">
    <h:outputText value="#{bean.message}" />
</h:panelGroup>
<h:panelGroup id="repeat">
    <ui:repeat value="#{bean.list}" var="obj">
        <rich:collapsiblePanel header="collapsible" toggleListener="#{bean.toggleListener}">
            <h:outputText value="Content" />
            <a4j:ajax event="switch" render="message" />
        </rich:collapsiblePanel>
    </ui:repeat>
</h:panelGroup>

public void toggleListener(PanelToggleEvent pte) {
    setMessage("panel " + (pte.getExpanded() ? "expanded" : "collapsed"));
}

"panel expanded" is never displayed because of the issue

When I queue the event during phase 3 (AbstractTogglePanel.processValiators) and set a @render of the collapsiblePanel to rerender the ui:repeat it works correctly.

<rich:collapsiblePanel … render="repeat, message">  

Unfortunately this prevents on* events from firing, I'm trying to find a way around it.

Does anyone know why and if we need to fire the events during phase 2?

[bleathem]

On 2014-11-21 03:07 AM, Michal Petrov wrote:

1. Components not keeping their state when the page is refreshed* although caused by the same thing I'd expect this is working as intended, and a panel losing its collapsed/expanded state doesn't look like a serious issue

The expected behavior is that a component inside a ui:repeat behave the

same as it does when not in a ui:repeat.  IOW if the component preserves

it's state on page refresh when not in a ui:repeat, then it should also

preserve it's state when nested in a ui:repeat.

2. State change events where the event doesn't retrieve the old value properly* this is certainly an issue

...

Does anyone know why and if we need to fire the events during phase 2?

I am not aware of any reason why one phase was chosen over the other.

If you can make it work using the Process Validations Phase then go for

it.  We can ask QE to run our functional test-suite on this component to

check for any regressions introduced by the phase change.

Nice investigations Michal, continue to keep us posted.

Brian

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev

[bleathem]

Pasting my reply into the forum, as the e-mial/forum bridge seems to have failed.:

---

1. Components not keeping their state when the page is refreshed* although caused by the same thing I'd expect this is working as intended, and a panel losing its collapsed/expanded state doesn't look like a serious issue

The expected behavior is that a component inside a ui:repeat behave the

same as it does when not in a ui:repeat.  IOW if the component preserves

it's state on page refresh when not in a ui:repeat, then it should also

preserve it's state when nested in a ui:repeat.

2. State change events where the event doesn't retrieve the old value properly* this is certainly an issue

...

Does anyone know why and if we need to fire the events during phase 2?

I am not aware of any reason why one phase was chosen over the other.

If you can make it work using the Process Validations Phase then go for

it.  We can ask QE to run our functional test-suite on this component to

check for any regressions introduced by the phase change.

Nice investigations Michal, continue to keep us posted.

[michpetrov]

I've checked the issues from our list with a simpler reproducer. Adding @render="id_of_repeat" seems to work, even without pushing the events to a later phase (in case of the tabPanel @render has to be added to every tab). However there is still one issue, the components share a stateHelper so if you collapse one panel every panel collapses. I have to check if there is a way to keep them separate. When I use datascrollers they each have their own state but tables do not.

[michpetrov]

There seems to be an issue with extendedDataTable, when I use ui:repeat to iterate over two lists instead of two different tables I get one table twice. Simple dataTable works fine. Serves to remind me to use different data sets next time.

However it looks like the fundamental issue is irresolvable. When the component tree is being built the constructor of the dataTable is only called once (the <ui:repeat> only has one child). Since there is only one instance of a UIComponent there is also only one ComponentStateHolder. Because we now have to render the whole ui:repeat the state is applied to every row. So as I described earlier changing a state of one row, e.g. sorting a column, will sort that column in every table. I'll contact the Mojarra team.

[michpetrov]

To recap:

The issue with EDT has been resolved and it wasn't related to this.

Prior to the change (JAVASERVERFACES-3152) the state of the row was saved when a server request was executed from that row. Currently that doesn't work, the ui:repeat isn't visited so the state isn't saved, in situations where components are checking their previous state they see the default state. Wrapping the ui:repeat in a panelGroup and rerendering helps somewhat - the ui:repeat is visited and state is saved but due to rerendering the state is applied to all rows. (e.g. sorting a table will sort all tables) so this is not the way to go (and rerendering only a single row of ui:repeat doesn't seem to be possible).

As far as I understand from the discussions there isn't a specification regarding how the ui:repeat is supposed to behave in situations like this, i.e. if this is the intended behavior or not.