[JBoss JIRA] (RF-13165) The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13165?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13165:
------------------------------------
To generalize the fix, the server-side check could check if the originating element id is a valid metacomponent id for the targeted component.
> The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
> ---------------------------------------------------------------------------------------------------------------
>
> Key: RF-13165
> URL: https://issues.jboss.org/browse/RF-13165
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Reporter: Brian Leathem
> Fix For: 5-Tracking
>
>
> An embedded _<a4j:ajax>_ tag in an extendedDataTable with the event rowclick_ does not work. 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 these lines of code:
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/res...
> {code}
> if (this.id && sourceElement.id.indexOf(this.id) == 0) { // otherwise parent element is definitely not JSF component
> var suffix = sourceElement.id.substring(this.id.length); // extract suffix
> if (suffix.match(/^[a-zA-Z]*$/) && isRichFacesComponent(this)) {
> parentElement = this;
> return false;
> }
> }
> {code}
> 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.
--
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
11 years, 2 months
[JBoss JIRA] (RF-12647) rich:dataTable rowclick with nested f:param
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12647?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12647:
------------------------------------
[~fabmars] I'm sorry to hear about your current status, I wish you a speedy recovery!
I couldn't find a reference to the new issue you mentioned, so I went ahead and created: RF-13165
> 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
11 years, 2 months
[JBoss JIRA] (RF-13165) The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13165?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13165:
-------------------------------
Issue Type: Bug (was: Feature Request)
> The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
> ---------------------------------------------------------------------------------------------------------------
>
> Key: RF-13165
> URL: https://issues.jboss.org/browse/RF-13165
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Reporter: Brian Leathem
> Fix For: 5-Tracking
>
>
> An embedded _<a4j:ajax>_ tag in an extendedDataTable with the event rowclick_ does not work. 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 these lines of code:
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/res...
> {code}
> if (this.id && sourceElement.id.indexOf(this.id) == 0) { // otherwise parent element is definitely not JSF component
> var suffix = sourceElement.id.substring(this.id.length); // extract suffix
> if (suffix.match(/^[a-zA-Z]*$/) && isRichFacesComponent(this)) {
> parentElement = this;
> return false;
> }
> }
> {code}
> 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.
--
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
11 years, 2 months
[JBoss JIRA] (RF-13165) The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
by Brian Leathem (JIRA)
Brian Leathem created RF-13165:
----------------------------------
Summary: The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
Key: RF-13165
URL: https://issues.jboss.org/browse/RF-13165
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: component-tables
Reporter: Brian Leathem
Fix For: 5-Tracking
An embedded _<a4j:ajax>_ tag in an extendedDataTable with the event rowclick_ does not work. 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 these lines of code:
https://github.com/richfaces/richfaces/blob/master/framework/src/main/res...
{code}
if (this.id && sourceElement.id.indexOf(this.id) == 0) { // otherwise parent element is definitely not JSF component
var suffix = sourceElement.id.substring(this.id.length); // extract suffix
if (suffix.match(/^[a-zA-Z]*$/) && isRichFacesComponent(this)) {
parentElement = this;
return false;
}
}
{code}
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.
--
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
11 years, 2 months
[JBoss JIRA] (RF-13162) Add support for the default-behavior faces-config property-extension to the CDK @Attribute annotation
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13162?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reopened RF-13162:
--------------------------------
> Add support for the default-behavior faces-config property-extension to the CDK @Attribute annotation
> -----------------------------------------------------------------------------------------------------
>
> Key: RF-13162
> URL: https://issues.jboss.org/browse/RF-13162
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: cdk
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: cdk-4.5.0.Alpha2
>
>
> Consider the xml component property definition:
> {code:title=From command-button-props.xml}
> <property>
> <description>
> Javascript code executed when a pointer button is clicked over this element.
> </description>
> <display-name>Button Click Script</display-name>
> <icon />
> <property-name>onclick</property-name>
> <property-class>java.lang.String</property-class>
> <property-extension>
> <cdk:pass-through>false</cdk:pass-through>
> <cdk:event-name default="true">click</cdk:event-name>
> <cdk:event-name>action</cdk:event-name>
> <default-behavior>true</default-behavior>
> </property-extension>
> </property>
> {code}
> There is currently no way to define this using the CDK @Attribute annotation - the _<default-behavior>_ annotation property is absent.
> To resolve this issue (blocking RF-12952) we need to add support for specifying the _default-behavior_ to the @Attribute annotation.
--
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
11 years, 2 months
[JBoss JIRA] (RF-13126) ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13126?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13126:
------------------------------------
Try:
{code}
"columnsWidthState":{"col0":"0px","col1":"250px","col2":"110px","col3":"100px","col4":"94px","col5":"250px","col6":"200px","col7":"120px","col8":"228px","col9":"100px"},
"columnsOrderState":["col0","col1","col2","col3","col4","col5","col6","col7","col8","col9"]
{code}
_columnsVisibility_ and _columnGroupingState_ are currently unsupported. Please file a jira issue to have them added to the Table State saving in RF 4/5.
> ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
> ----------------------------------------------------------------------------------------------------------
>
> Key: RF-13126
> URL: https://issues.jboss.org/browse/RF-13126
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 5.0.0.Alpha1
> Environment: Windows / Tomcat 7 / JDK 1.7 (Firefox & IE)
> Reporter: Steven W.
>
> In prior 3.x release the ExtendedDataTable control supported TableState data for sizing of columns - this worked relatively well *however* there is/was a bug such that the columns headers above the table did *not* align properly with the data rows of the table below; this could be partially accommodated by specifying a size for the column (in the TableState data) that was wider than the longest string in the column data as he initial / minimum size.
> In subsequent release (in 4.x time frame I believe) the control was refactored and the TableState capability as a whole was lost - I saw this in another report on the forum or Jira though not the same but other related issues may be RF-4855 + RF-13094 and RF-13095 ; the report I remember reading, however, is that this TableState functionality was lost during the refactoring and was then said to be restored in a subsequent release.
> I am now using Version 5 of RichFaces to include the first milestone and latest (overnight) snapshot and am confirming this column header sizing AND/OR TableState table header sizing issue(s) still remain, regardless of prior attempts to include TableState data recognition and, if/as so, the widths of the column headers does not respect the TableState data nor do they conform to the column widths of the data in the rows below.
--
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
11 years, 2 months
[JBoss JIRA] (RF-13095) extendedDataTable tableState setter not called on column resize/reorder
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13095?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13095:
------------------------------------
See comments in RF-13126.
> extendedDataTable tableState setter not called on column resize/reorder
> -----------------------------------------------------------------------
>
> Key: RF-13095
> URL: https://issues.jboss.org/browse/RF-13095
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23, tested on Firefox 22 and Chrome 28.
> Reporter: Salvo Isaja
> Assignee: Brian Leathem
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Not sure if this qualifies as a bug or a feature request.
> I have an extendedDataTable with the tableState attribute bound to a String property of a backing bean (tried both a request scoped bean on a transient view and a session scoped bean on a stateful view).
> When resizing or reordering columns, an Ajax request is posted to the server, and I correctly see the new column layouts in the request, but the setter of the tableState property in the backing bean is not called. If I execute @form on a a4j:commandLink or commandButton, it is called instead.
> Thanks
--
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
11 years, 2 months