[JBoss JIRA] (RF-13776) a4j:ajax problem with hierarchical component IDs
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13776?page=com.atlassian.jira.plugin.s... ]
Michael B edited comment on RF-13776 at 8/14/14 10:33 AM:
----------------------------------------------------------
[~bleathem] meanwhile I've tried the 2 things you asked for - although the ID for the second test has to be a little different.
bq. 1. Replace the JSF <h:selectBooleanCheckbox> with a RichFaces component?
I've replaced the selectBooleanCheckbox with a rich:select and an a4j:ajax event="selectitem". In this case the event is fired correctly - even if the ids are similar. The reason for that is, that the select has the {code}element[richfaces.RICH_CONTAINER]{code} and so a search for a parent is not required.
bq. 2. Check what RichFaces.$(document.getElementById("form:treeNode:treeNodeSelectBox")) evaluates to?
Since a treeNode cannot be used without a valid tree around, a valid id will be "form:tree:treeModelAdapter.0:treeNodeSelectBox".
A test of {code}document.getElementById("form:tree:treeModelAdapter.0:treeNodeSelectBox"){code} evaluates to the checkbox, while a test of {code}RichFaces.$( document.getElementById("form:tree:treeModelAdapter.0:treeNodeSelectBox") ){code} evaluates to 'undefined', since {code}element[richfaces.RICH_CONTAINER]{code} is not defined for the selectBooleanCheckbox.
In comparison to that for a "rich:select":
A test of {code}document.getElementById("form:tree:treeModelAdapter.0:treeNodeOptionSelectorInput"){code} evaluates to the rich:select, while a test of {code}RichFaces.$( document.getElementById("form:tree:treeModelAdapter.0:treeNodeOptionSelectorInput") ){code} evaluates to the component (source) itself, since {code}element[richfaces.RICH_CONTAINER]{code} is defined.
So I think there are basically 2 problems in this case:
# The JavaScript code for evaluating the event source component in {code}searchForComponentRootOrReturn(sourceElement);{code} is wrong in this context, because it only searches for richfaces components. If {code}if (sourceElement.id && !richfaces.$(sourceElement)) {{code} would evaluate to the selectBooleanCheckbox as a valid event source, the search for the parent (which in turn produces the problem with the ids) would not be required.
# The JavaScript code should respect the component separator while searching for parents to avoid identifying the wrong component in case of similar ids.
was (Author: michaelb80):
[~bleathem] meanwhile I've tried the 2 things you asked for - although the ID for the second test has to be a little different.
bq. 1. Replace the JSF <h:selectBooleanCheckbox> with a RichFaces component?
I've replaced the selectBooleanCheckbox with a rich:select and an a4j:ajax event="selectitem". In this case the event is fired correctly - even if the ids are similar. The reason for that is, that the select has the {code}element[richfaces.RICH_CONTAINER]{code} and so a search for a parent is not required.
bq. 2. Check what RichFaces.$(document.getElementById("form:treeNode:treeNodeSelectBox")) evaluates to?
Since a treeNode cannot be used without a valid tree around, a valid id will be "form:tree:treeModelAdapter.0:treeNodeSelectBox".
A test of {code}document.getElementById("form:tree:treeModelAdapter.0:treeNodeSelectBox"){code} evaluates to the checkbox, while a test of {code}RichFaces.$( document.getElementById("form:tree:treeModelAdapter.0:treeNodeSelectBox") ){code} evaluates to 'undefined', since {code}element[richfaces.RICH_CONTAINER]{code} is not defined for the selectBooleanCheckbox.
In comparison to that for a "rich:select":
A test of {code}document.getElementById("form:tree:treeModelAdapter.0:treeNodeOptionSelectorInput"){code} evaluates to the rich:select, while a test of {code}RichFaces.$( document.getElementById("form:tree:treeModelAdapter.0:treeNodeOptionSelectorInput") ){code} evaluates to the component (source) itself, since {code}element[richfaces.RICH_CONTAINER]{code} is defined.
So I think there are basically 2 problems in this case:
# The JavaScript code for evaluating the event source component in {code}searchForComponentRootOrReturn(sourceElement);{code} is wrong in this context, because it only searches for richfaces components. If {code}if (sourceElement.id && !isRichFacesComponent(sourceElement)) {{code} would evaluate to the selectBooleanCheckbox as a valid event source, the search for the parent (which in turn produces the problem with the ids) would not be required.
# The JavaScript code should respect the component separator while searching for parents to avoid identifying the wrong component in case of similar ids.
> a4j:ajax problem with hierarchical component IDs
> ------------------------------------------------
>
> Key: RF-13776
> URL: https://issues.jboss.org/browse/RF-13776
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.7
> Environment: RichFaces 4.3.7
> Mojarra 2.1.29
> Java 7 Update 67 (x64)
> Tomcat 7.0.52 (x64)
> Reporter: Michael B
>
> First of all: this is a bug report related to RF-12616.
> The actionListener of an a4j:ajax-enhanced component is not invoked on the server side. In a nutshell the problem is due to the request parameter "javax.faces.source" not matching the id of the component for which the AjaxBehaviorEvent is bound.
> The problem occurs when you assign hierarchical component ids in your xhtml.
> Here is a condensed snippet xhtml illustrating the problem:
> {code:title=Snippet|borderStyle=solid}
> <rich:treeNode id="treeNode">
> <h:selectBooleanCheckbox id="treeNodeSelectBox">
> <a4j:ajax event="click" execute="@this" listener="#{someManagedBean.onCheckboxClick}" />
> </h:selectBooleanCheckbox>
> </rich:treeNode>
> {code}
> As you can see, the id of the selectBooleanCheckbox begins with the id of the treeNode.
> The RichFaces JavaScript handler introduced a function to obviously evaluate the correct component id for the event (which is then passed as request parameter 'javax.faces.source' in the AJAX request).
> {code:title=RichFaces JS-Snippet|borderStyle=solid}
> richfaces.ajax = function(source, event, options) {
> var options = options || {};
>
> var sourceId = getSourceId(source, options);
> var sourceElement = getSourceElement(source);
>
> // event source re-targeting finds a RichFaces component root
> // to setup javax.faces.source correctly - RF-12616)
> if (sourceElement) {
> source = searchForComponentRootOrReturn(sourceElement);
> }
>
> ...
> /*
> * Returns RichFaces component root for given element in the list of ancestors of sourceElement.
> * Otherwise returns sourceElement if RichFaces component root can't be located.
> */
> var searchForComponentRootOrReturn = function(sourceElement) {
> if (sourceElement.id && !richfaces.$(sourceElement)) {
> var parentElement = false;
> jQuery(sourceElement).parents().each(function() {
> 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]*$/) && richfaces.$(this)) {
> parentElement = this;
> return false;
> }
> }
> });
> if (parentElement !== false) {
> return parentElement;
> }
> }
> return sourceElement;
> };
> {code}
> The problem is within the function "searchForComponentRootOrReturn" which in this special case of id-hierarchy evaluates to the wrong element. The correct element to be returned here would be the "sourceElement" (selectBooleanCheckbox with the id "treeNodeSelectBox" in the example above), but the code evaluates to a "parentElement" (treeNode in the example above) due to its id "treeNode" being a prefix of the component which fired the event.
> It took me a whole day to figure that one out, since there is no useful output neither in a4j:log nor in server side logging in a case where the parameter "javax.faces.source" does not match the component id. In fact the AJAX request is executed just fine, only the event is never queued...
> (See Mojarra HtmlBasicRenderer => decodeBehaviors and its check method isBehaviorSource)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13776) a4j:ajax problem with hierarchical component IDs
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13776?page=com.atlassian.jira.plugin.s... ]
Michael B commented on RF-13776:
--------------------------------
[~bleathem] meanwhile I've tried the 2 things you asked for - although the ID for the second test has to be a little different.
bq. 1. Replace the JSF <h:selectBooleanCheckbox> with a RichFaces component?
I've replaced the selectBooleanCheckbox with a rich:select and an a4j:ajax event="selectitem". In this case the event is fired correctly - even if the ids are similar. The reason for that is, that the select has the {code}element[richfaces.RICH_CONTAINER]{code} and so a search for a parent is not required.
bq. 2. Check what RichFaces.$(document.getElementById("form:treeNode:treeNodeSelectBox")) evaluates to?
Since a treeNode cannot be used without a valid tree around, a valid id will be "form:tree:treeModelAdapter.0:treeNodeSelectBox".
A test of {code}document.getElementById("form:tree:treeModelAdapter.0:treeNodeSelectBox"){code} evaluates to the checkbox, while a test of {code}RichFaces.$( document.getElementById("form:tree:treeModelAdapter.0:treeNodeSelectBox") ){code} evaluates to 'undefined', since {code}element[richfaces.RICH_CONTAINER]{code} is not defined for the selectBooleanCheckbox.
In comparison to that for a "rich:select":
A test of {code}document.getElementById("form:tree:treeModelAdapter.0:treeNodeOptionSelectorInput"){code} evaluates to the rich:select, while a test of {code}RichFaces.$( document.getElementById("form:tree:treeModelAdapter.0:treeNodeOptionSelectorInput") ){code} evaluates to the component (source) itself, since {code}element[richfaces.RICH_CONTAINER]{code} is defined.
So I think there are basically 2 problems in this case:
# The JavaScript code for evaluating the event source component in {code}searchForComponentRootOrReturn(sourceElement);{code} is wrong in this context, because it only searches for richfaces components. If {code}if (sourceElement.id && !isRichFacesComponent(sourceElement)) {{code} would evaluate to the selectBooleanCheckbox as a valid event source, the search for the parent (which in turn produces the problem with the ids) would not be required.
# The JavaScript code should respect the component separator while searching for parents to avoid identifying the wrong component in case of similar ids.
> a4j:ajax problem with hierarchical component IDs
> ------------------------------------------------
>
> Key: RF-13776
> URL: https://issues.jboss.org/browse/RF-13776
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.7
> Environment: RichFaces 4.3.7
> Mojarra 2.1.29
> Java 7 Update 67 (x64)
> Tomcat 7.0.52 (x64)
> Reporter: Michael B
>
> First of all: this is a bug report related to RF-12616.
> The actionListener of an a4j:ajax-enhanced component is not invoked on the server side. In a nutshell the problem is due to the request parameter "javax.faces.source" not matching the id of the component for which the AjaxBehaviorEvent is bound.
> The problem occurs when you assign hierarchical component ids in your xhtml.
> Here is a condensed snippet xhtml illustrating the problem:
> {code:title=Snippet|borderStyle=solid}
> <rich:treeNode id="treeNode">
> <h:selectBooleanCheckbox id="treeNodeSelectBox">
> <a4j:ajax event="click" execute="@this" listener="#{someManagedBean.onCheckboxClick}" />
> </h:selectBooleanCheckbox>
> </rich:treeNode>
> {code}
> As you can see, the id of the selectBooleanCheckbox begins with the id of the treeNode.
> The RichFaces JavaScript handler introduced a function to obviously evaluate the correct component id for the event (which is then passed as request parameter 'javax.faces.source' in the AJAX request).
> {code:title=RichFaces JS-Snippet|borderStyle=solid}
> richfaces.ajax = function(source, event, options) {
> var options = options || {};
>
> var sourceId = getSourceId(source, options);
> var sourceElement = getSourceElement(source);
>
> // event source re-targeting finds a RichFaces component root
> // to setup javax.faces.source correctly - RF-12616)
> if (sourceElement) {
> source = searchForComponentRootOrReturn(sourceElement);
> }
>
> ...
> /*
> * Returns RichFaces component root for given element in the list of ancestors of sourceElement.
> * Otherwise returns sourceElement if RichFaces component root can't be located.
> */
> var searchForComponentRootOrReturn = function(sourceElement) {
> if (sourceElement.id && !richfaces.$(sourceElement)) {
> var parentElement = false;
> jQuery(sourceElement).parents().each(function() {
> 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]*$/) && richfaces.$(this)) {
> parentElement = this;
> return false;
> }
> }
> });
> if (parentElement !== false) {
> return parentElement;
> }
> }
> return sourceElement;
> };
> {code}
> The problem is within the function "searchForComponentRootOrReturn" which in this special case of id-hierarchy evaluates to the wrong element. The correct element to be returned here would be the "sourceElement" (selectBooleanCheckbox with the id "treeNodeSelectBox" in the example above), but the code evaluates to a "parentElement" (treeNode in the example above) due to its id "treeNode" being a prefix of the component which fired the event.
> It took me a whole day to figure that one out, since there is no useful output neither in a4j:log nor in server side logging in a case where the parameter "javax.faces.source" does not match the component id. In fact the AJAX request is executed just fine, only the event is never queued...
> (See Mojarra HtmlBasicRenderer => decodeBehaviors and its check method isBehaviorSource)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13750) Upgrade testing dependencies
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13750?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13750:
-------------------------------
Original Estimate: 4 hours
Remaining Estimate: 4 hours
Sprint: 4.5.0.Beta1 - Upgrade Sprint
> Upgrade testing dependencies
> ----------------------------
>
> Key: RF-13750
> URL: https://issues.jboss.org/browse/RF-13750
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Alpha3
> Reporter: Pavol Pitonak
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Upgrade following dependencies in build/pom.xml:
> * Arquillian Core 1.1.4.Final -> 1.1.5.Final
> * Arquillian Drone 1.3.0.Final -> 1.3.1.Final
> * Arquillian Tomcat container 1.0.0.CR6 -> 1.0.0.CR7
> * Selenium 2.41.0 -> 2.42.0
> * Arquillian Graphene 2.0.3.Final -> 2.1.0.Alpha1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13750) Upgrade testing dependencies
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13750?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13750:
-------------------------------
Description:
Upgrade following dependencies in build/pom.xml:
* Arquillian Core 1.1.4.Final -> 1.1.5.Final
* Arquillian Drone 1.3.0.Final -> 1.3.1.Final
* Arquillian Tomcat container 1.0.0.CR6 -> 1.0.0.CR7
* Selenium 2.41.0 -> 2.42.0
* Arquillian Graphene 2.0.3.Final -> 2.1.0.Alpha1
was:
Upgrade following dependencies in build/pom.xml:
* Arquillian Core 1.1.4.Final -> 1.1.5.Final
* Arquillian Drone 1.3.0.Final -> 1.3.1.Final
* Arquillian Tomcat container 1.0.0.CR6 -> 1.0.0.CR7
* Selenium 2.41.0 -> 2.42.0
> Upgrade testing dependencies
> ----------------------------
>
> Key: RF-13750
> URL: https://issues.jboss.org/browse/RF-13750
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Alpha3
> Reporter: Pavol Pitonak
>
> Upgrade following dependencies in build/pom.xml:
> * Arquillian Core 1.1.4.Final -> 1.1.5.Final
> * Arquillian Drone 1.3.0.Final -> 1.3.1.Final
> * Arquillian Tomcat container 1.0.0.CR6 -> 1.0.0.CR7
> * Selenium 2.41.0 -> 2.42.0
> * Arquillian Graphene 2.0.3.Final -> 2.1.0.Alpha1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13750) Upgrade testing dependencies
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13750?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak updated RF-13750:
-------------------------------
Fix Version/s: 4.5.0.Beta1
> Upgrade testing dependencies
> ----------------------------
>
> Key: RF-13750
> URL: https://issues.jboss.org/browse/RF-13750
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Alpha3
> Reporter: Pavol Pitonak
> Fix For: 4.5.0.Beta1
>
>
> Upgrade following dependencies in build/pom.xml:
> * Arquillian Core 1.1.4.Final -> 1.1.5.Final
> * Arquillian Drone 1.3.0.Final -> 1.3.1.Final
> * Arquillian Tomcat container 1.0.0.CR6 -> 1.0.0.CR7
> * Selenium 2.41.0 -> 2.42.0
> * Arquillian Graphene 2.0.3.Final -> 2.1.0.Alpha1
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13774) Upgrade MyFaces to 2.2.4
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13774?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13774:
-------------------------------
Sprint: 4.5.0.Beta1 - Doc Sprint
> Upgrade MyFaces to 2.2.4
> ------------------------
>
> Key: RF-13774
> URL: https://issues.jboss.org/browse/RF-13774
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Affects Versions: 4.5.0.Alpha3
> Reporter: Pavol Pitonak
> Labels: myfaces
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> MyFaces version defined in build/pom.xml is 2.1.10 which is outdated. There is newer 2.1.15 but since we depend on Mojarra 2.2.x, we should upgrade MyFaces to *2.2.4*.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13774) Upgrade MyFaces to 2.2.4
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13774?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13774:
-------------------------------
Sprint: (was: 4.5.0.Beta1 - Upgrade Sprint)
> Upgrade MyFaces to 2.2.4
> ------------------------
>
> Key: RF-13774
> URL: https://issues.jboss.org/browse/RF-13774
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Affects Versions: 4.5.0.Alpha3
> Reporter: Pavol Pitonak
> Labels: myfaces
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> MyFaces version defined in build/pom.xml is 2.1.10 which is outdated. There is newer 2.1.15 but since we depend on Mojarra 2.2.x, we should upgrade MyFaces to *2.2.4*.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13778) RF-45 cyclic dependency on richfaces-parent
by Pavol Pitonak (JIRA)
Pavol Pitonak created RF-13778:
----------------------------------
Summary: RF-45 cyclic dependency on richfaces-parent
Key: RF-13778
URL: https://issues.jboss.org/browse/RF-13778
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: build/distribution
Affects Versions: 4.5.0.Alpha3
Reporter: Pavol Pitonak
Priority: Blocker
Historically there is a dependency in .../jsf-tests/pom.xml on richfaces-parent which used to be a standalone project/repo in 4.3.x
{code}
<parent>
<groupId>org.richfaces</groupId>
<artifactId>richfaces-parent</artifactId>
<version>12</version>
</parent>
{code}
However nowadays in 4.5.x there is playing the role of parent the
richfaces/pom.xml
https://github.com/richfaces/richfaces/blob/master/pom.xml
{code}
<groupId>org.richfaces</groupId>
<artifactId>richfaces-parent</artifactId>
<packaging>pom</packaging>
<version>4.5.0-SNAPSHOT</version>
<name>RichFaces Parent</name>
{code}
which makes a cyclic dependency
jsf-test --> richfaces --> jsf-test
as there are inside https://github.com/richfaces/richfaces/blob/master/build/pom.xml
referenced dependencies for jsf-tests
{code}
<dependency>
<groupId>org.jboss.test-jsf</groupId>
<artifactId>htmlunit-client</artifactId>
<version>${version.jsf-test}</version>
<exclusions>
<exclusion>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.test-jsf</groupId>
<artifactId>jsf-test-stage</artifactId>
<version>${version.jsf-test}</version>
</dependency>
<dependency>
<groupId>org.jboss.test-jsf</groupId>
<artifactId>jsf-mock</artifactId>
<version>${version.jsf-test}</version>
</dependency>
<dependency>
<groupId>org.jboss.test-jsf</groupId>
<artifactId>jsf-mockito</artifactId>
<version>${version.jsf-test}</version>
</dependency>
<dependency>
<groupId>org.jboss.test-jsf</groupId>
<artifactId>jsf-test-scriptunit</artifactId>
<version>${version.jsf-test}</version>
</dependency>
{code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months
[JBoss JIRA] (RF-13777) Upgrade Graphene do 2.1.0.Alpha1
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13777?page=com.atlassian.jira.plugin.s... ]
Juraj Húska reassigned RF-13777:
--------------------------------
Assignee: Juraj Húska
> Upgrade Graphene do 2.1.0.Alpha1
> --------------------------------
>
> Key: RF-13777
> URL: https://issues.jboss.org/browse/RF-13777
> Project: RichFaces
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Juraj Húska
>
> Upgrade of Graphene to 2.1.0.Alpha1 would have following benefits:
> * there is a fix which will enable testing of fileUpload component
> * there is a screenshooter which can replace the custom solution in RF
> * in 2.1.x will be added XHRHalter, which will make testing of {{a4j:attachQueue}} and {{a4j:queue}} more deterministic.
> Even it is in Alpha version, we consider it pretty stable. And if we want upgrade we should do it ASAP.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 3 months