[
https://issues.jboss.org/browse/RF-12647?page=com.atlassian.jira.plugin.s...
]
Brian Leathem commented on RF-12647:
------------------------------------
h5. Regarding "RF 4 Sample 1"
It is a JSF 2 spec limitation that you cannot nest components in a JSF Behaviour, or
rather, that nesting components in a behaviour changes the target of that behaviour.
There is a spec issue filed addressing this, be sure to vote for it:
*
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-742
* (along with the initiaitng mojarra bug:
https://java.net/jira/browse/JAVASERVERFACES-1532)
----
h5. Regarding "RF 4 Sample 2"
The relevant code snippet:
{code}
<a4j:ajax event="rowclick" render="shippingEditForm"
listener="#{shippingEdit.setId(shipping.id)}"/>
{code}
This *should* work. A google search quickly shows one how many people expect it to work.
I dug in to find out _why_ it doesn't work:
When a HTML element triggers an ajax event, a check is performed on the server-side to see
if the HTML element that triggered the event is the JSF component that is being decoded.
This is done in this line of code:
https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
{code}
if (behaviorSource != null && behaviorSource.equals(clientId)) {
...
{code}
Before the request is sent to the server, we check if the originating element of an event
is from a component, and "re-target" it if not (see:RF-12616, RF-12715). This
is done in this line of code:
https://github.com/richfaces/richfaces/blob/master/framework/src/main/res...
``
This re-targeting works well, as for the most part elements DOM ids within components use
the _#\{clientId}Qualifier_ syntax. However this breaks down with table rows, where the
":" separator is used. This is the same separator used to separate JSF
component id's in the clientId. For example, a table with the clilentId
"form:edt" will have rows with DOM id "myForm:edt:5:n".
So we need to fix the client-side re-targeting to work for table rows.
[~fabmars] Would you mind filing a new issue to rack this? This issue has several
"issues" wrapped within it. Then we can close this issue and move forward
solving the specific problem that arose from this report.
----
h5. Regarding "RF 4 Sample 3"
Using the _a4j:jsFunction_ is indeed the currently promoted workaround to meet this use
case.
rich:dataTable rowclick with nested f:param
-------------------------------------------
Key: RF-12647
URL:
https://issues.jboss.org/browse/RF-12647
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: component-tables
Affects Versions: 4.3.0.M2
Environment: Win7, JDK7, Glassfish3, Mojarra 2.1.14, SeamFaces, RF 4.x.x
Reporter: Fab Mars
Labels: waiting_on_user
During my migration from RF 3.3 I found this:
Before (with RF 3.3.3):
{code:xml|title="RF 3 Sample"}
<rich:dataTable id="shippingList"
value="#{billingLister.allShippings}" var="shipping">
<a4j:support event="onRowClick" reRender="shippingEditForm">
<a4j:actionparam name="shippingId" value="#{shipping.id}"
assignTo="#{shippingEdit.id}"/>
</a4j:support>
<rich:column>
<f:facet name="header">
<h:outputText value="Destination"/>
</f:facet>
<h:outputText value="#{shipping.destinationCountry.name}" />
</rich:column>
<!-- other columns here -->
</rich:dataTable>
{code}
There was nothing really impacting on the migration guide
https://community.jboss.org/wiki/RichFacesMigrationGuide33x-4xMigration-C...
So I logically did that with RF4.x.x:
{code:xml|title="RF 4 Sample 1"}
<rich:dataTable id="shippingList"
value="#{billingLister.allShippings}" var="shipping">
<a4j:ajax event="rowclick" render="shippingEditForm">
<a4j:param name="shippingId" value="#{shipping.id}"
assignTo="#{shippingEdit.id}"/>
</a4j:ajax>
<rich:column>
<f:facet name="header">
<h:outputText value="Destination"/>
</f:facet>
<h:outputText value="#{shipping.destinationCountry.name}" />
</rich:column>
<!-- other columns here -->
</rich:dataTable>
{code}
But the a4j:ajax isn't triggered (not at all, it's NOT a param assignment issue).
To start having something that responds, one needs to remove the a4j:param and do it
EL-newlook style.
{code:xml|title="RF 4 Sample 2"}
<a4j:ajax event="rowclick" render="shippingEditForm"
listener="#{shippingEdit.setId(shipping.id)}"/>
{code}
Anyhow we're close to RF-11446 and whenever that one gets fixed, one should check
whether this case here is also solved.
But wait, even that doesn't work: when one clicks on a row with that code, the
listener is called but an ArrayIndexOutOfBoundsException is thrown because the clientID
that's actually passed into UIDataAdapter#invokeOnRow is the id of the dataTable
itself, NOT this of the row/cell. Hence, String rowId = clientId.substring(baseId.length()
+ 1) ends up tragically.
So...to make it really work, you have to do what's described here:
https://community.jboss.org/thread/174063 and not fall into the trap of RF-11446.
Working code (RF 4.2.3+)
{code:xml|title="RF 4 Sample 3"}
<a4j:jsFunction name="shippingListRowClick"
render="shippingEditForm">
<a4j:param name="shippingId" assignTo="#{shippingEdit.id}"/>
</a4j:jsFunction>
<rich:dataTable id="shippingList"
value="#{billingLister.allShippings}" var="shipping"
onrowclick="shippingListRowClick(#{shipping.id});">
<rich:column>
<f:facet name="header">
<h:outputText value="Destination"/>
</f:facet>
<h:outputText value="#{shipping.destinationCountry.name}" />
</rich:column>
<!-- other columns here -->
</rich:dataTable>
{code}
All that...for that.
Overall that makes quite a difference between RF 3.3 and RF 4.x. I'd say we have a
couple of regressions. Or at least that needs an extra clarification in the documentation
and migration guide. Thank you.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira