[
https://issues.jboss.org/browse/RF-11447?page=com.atlassian.jira.plugin.s...
]
Brendan Healey commented on RF-11447:
-------------------------------------
The complete event is not supported by the h:selectOneMenu tag, and I don't
see how it would help on the a4j:ajax nested within the ETD.
It's working using <a4j:ajax oncomplete="selectMenuComplete()"/>
within the
selectOneMenu, and this: <a4j:jsFunction name="selectMenuComplete"
render="teamTable"/>.
I will retry your inplaceSelect component now that I've stopped using full state
saving on the view in question, previously I'd had a few problems.
Having ported a 200k+ LOC primefaces application to RF 4 it has been a good call to
make the transition. RF 4.1 is shaping up really well and it's a really well thought
out framework, with hidden depths. Great work.
extendedDataTable re-rendering problem with h:selectOneMenu and
a4j:ajax
------------------------------------------------------------------------
Key: RF-11447
URL:
https://issues.jboss.org/browse/RF-11447
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 4.0.0.Final
Environment: Mojarra 2.1.3.
Reporter: Brendan Healey
Labels: waiting_on_user
I've got a h:selectOneMenu inside a column of an extendedDataTable which can
be used to modify a property of the current row. The changeInviteState
valueChangeListener persists the modification to the database. What I would
expect to happen in the below example is that the getEventTeamList() method
returns the current data, selectOneMenu is used to make a change and the
nested "<a4j:ajax render="teamTable"/>" causes the table to be
re-rendered
(the table getter getEventTeamList should be called to refresh the data).
The problem is that this re-rendering of the table doesn't happen. I see the
value change listener firing but the table value getter is not executed after
the VCL.
The importance of being able to re-render the table after the data change is
that when using optimistic locking the table will contain a stale version
number and subsequent modification attempts will fail (unless you refresh the
data before making a modification, but that is an inferior approach).
Note that removing <a4j:ajax event="selectionchange" makes no difference.
{code}
<rich:extendedDataTable
id="teamTable"
binding="#{bean.teamTable}"
value="#{bean.eventTeamList}" var="var"
selectionMode="single"
selection="#{bean.selectedTeamRow}">
<a4j:ajax event="selectionchange"
listener="#{bean.teamRowSelect}"/>
<rich:column style="text-align: center">
<h:selectOneMenu value="#{var.inviteState}"
valueChangeListener="#{bean.changeInviteState}"
rendered="#{bean.showStatusInput}">
<f:selectItems value="#{bean.teamStatusOptions}"
var="svar"
itemLabel="#{svar.localName}" itemValue="#{svar}"/>
<a4j:ajax render="teamTable"/>
</h:selectOneMenu>
</rich:column>
</rich:extendedDataTable>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira