12:07 a.m.
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:
{code:jivemacro_uid=_14165667147859736|class=jive_text_macro jive_macro_code
_jivemacro_uid_14165667147859736}
<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>
{code}
{code:jivemacro_uid=_14165667211008357|class=jive_text_macro jive_macro_code
_jivemacro_uid_14165667211008357}
public void toggleListener(PanelToggleEvent pte) {
setMessage("panel " + (pte.getExpanded() ? "expanded" :
"collapsed"));
}
{code}
"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.
{code:modifiedtitle=true|jivemacro_uid=_14165668382394427|class=jive_text_macro
jive_macro_code _jivemacro_uid_14165668382394427}<rich:collapsiblePanel …
render="repeat, message"> {code}
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?
Posted by forums
Original post: https://developer.jboss.org/message/910997#910997
11:59 a.m.
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
4:33 a.m.
Pasting my reply into the forum, as the e-mial/forum bridge seems to have failed.:
----
{quote:class=jive_text_macro jive_macro_quote}
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
{quote}
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.
{quote:class=jive_text_macro jive_macro_quote}
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?
{quote}
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.
Posted by forums
Original post: https://developer.jboss.org/message/911464#911464
6:30 a.m.
I've checked the issues from our list
(https://issues.jboss.org/browse/RF-13801?jql=labels%20%3D%20%22uiRepeat%2...)
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.
Posted by forums
Original post: https://developer.jboss.org/message/911485#911485
6:27 a.m.
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.
Posted by forums
Original post: https://developer.jboss.org/message/912033#912033
3 a.m.
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.
Posted by forums
Original post: https://developer.jboss.org/message/915475#915475
4103
days inactive
4152
days old
5 comments
3 participants
participants (3)
-
Brian Leathem -
Brian Leathem -
Michal Petrov