[richfaces-issues] [JBoss JIRA] (RF-12647) rich:dataTable rowclick with nested f:param

Fab Mars (JIRA) jira-events at lists.jboss.org
Wed Sep 4 12:26:03 EDT 2013


    [ https://issues.jboss.org/browse/RF-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801620#comment-12801620 ] 

Fab Mars commented on RF-12647:
-------------------------------

TO make a long story short: You did right.
                
> 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-ComponentsMigration-RichIterationComponents
> 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


More information about the richfaces-issues mailing list