[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 commented on RF-13777:
----------------------------------
I am going to create a feature branch where I will test such a upgrade.
> Upgrade Graphene do 2.1.0.Alpha1
> --------------------------------
>
> Key: RF-13777
> URL: https://issues.jboss.org/browse/RF-13777
> Project: RichFaces
> Issue Type: Component Upgrade
> …
[View More] 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)
[View Less]
10 years, 6 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 edited comment on RF-13777 at 8/14/14 7:13 AM:
-----------------------------------------------------------
I am going to create a feature branch where I will test such an upgrade.
was (Author: jhuska):
I am going to create a feature branch where I will test such a upgrade.
> Upgrade Graphene do 2.1.0.Alpha1
> --------------------------------
>
> Key: RF-13777
> …
[View More] 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)
[View Less]
10 years, 6 months
[JBoss JIRA] (RF-13777) Upgrade Graphene do 2.1.0.Alpha1
by Juraj Húska (JIRA)
Juraj Húska created RF-13777:
--------------------------------
Summary: 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
Upgrade of Graphene to 2.1.0.Alpha1 would have …
[View More]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)
[View Less]
10 years, 6 months
[JBoss JIRA] (RF-11332) Improve AutoComplete component to support Object values separate from AutoCompleteinput field
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11332?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-11332.
--------------------------------
Labels: (was: gss)
Fix Version/s: (was: 4.5.0.Beta1)
Resolution: Done
> Improve AutoComplete component to support Object values separate from AutoCompleteinput field
> ---------------------------------------------------------------------------------------------
>
> Key: RF-11332
> …
[View More] URL: https://issues.jboss.org/browse/RF-11332
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.1.0.Milestone1
> Reporter: Cody Lerum
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> {code}
> <rich:autocomplete id="client" value="#{newService.client}" autocompleteMethod="#{entitySearch.appEntityClients}" var="_a" fetchValue="#{_a}">
> <h:outputText value="#{_a.name}" />
> </rich:autocomplete>
> {code}
> Given the above code the fetchValue which is placed in the generated inputText box is what is actually submitted with the form.
> To support POJO selects what is needed is to have a value and a valueLabel so that the fetchValue can be displayed to the user but the acutal converted object value is submitted to the form.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
[View Less]
10 years, 6 months
[JBoss JIRA] (RF-11332) Improve AutoComplete component to support Object values separate from AutoCompleteinput field
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11332?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-11332:
------------------------------------
On further investigation, it seems that adding autocomplete functionality to the select component is simpler.
> Improve AutoComplete component to support Object values separate from AutoCompleteinput field
> ---------------------------------------------------------------------------------------------
>
> Key: …
[View More]RF-11332
> URL: https://issues.jboss.org/browse/RF-11332
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.1.0.Milestone1
> Reporter: Cody Lerum
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> {code}
> <rich:autocomplete id="client" value="#{newService.client}" autocompleteMethod="#{entitySearch.appEntityClients}" var="_a" fetchValue="#{_a}">
> <h:outputText value="#{_a.name}" />
> </rich:autocomplete>
> {code}
> Given the above code the fetchValue which is placed in the generated inputText box is what is actually submitted with the form.
> To support POJO selects what is needed is to have a value and a valueLabel so that the fetchValue can be displayed to the user but the acutal converted object value is submitted to the form.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
[View Less]
10 years, 6 months
[JBoss JIRA] (RF-13776) a4j:ajax problem with hierarchical component IDs
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13776?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13776 at 8/13/14 6:22 PM:
-------------------------------------------------------------
The RF 4.5 version of the method is a bit more explicit:
https://github.com/richfaces/richfaces/blob/master/core/src/main/resource...
{code}
var searchForComponentRootOrReturn = function(sourceElement) {
if (sourceElement.id && !isRichFacesComponent(sourceElement)) {
…
[View More] var parentElement = false;
$(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]*$/) && isRichFacesComponent(this)) {
parentElement = this;
return false;
}
}
});
if (parentElement !== false) {
return parentElement;
}
}
return sourceElement;
};
{code}
We should perhaps take the component separator into account when doing the suffix comparison.
was (Author: bleathem):
The RF5 version of the method is a bit more explicit:
https://github.com/richfaces/richfaces/blob/master/core/src/main/resource...
{code}
var searchForComponentRootOrReturn = function(sourceElement) {
if (sourceElement.id && !isRichFacesComponent(sourceElement)) {
var parentElement = false;
$(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]*$/) && isRichFacesComponent(this)) {
parentElement = this;
return false;
}
}
});
if (parentElement !== false) {
return parentElement;
}
}
return sourceElement;
};
{code}
We should perhaps take the component separator into account when doing the suffix comparison.
> 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)
[View Less]
10 years, 6 months
[JBoss JIRA] (RF-13776) a4j:ajax problem with hierarchical component IDs
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13776?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13776:
------------------------------------
The RF5 version of the method is a bit more explicit:
https://github.com/richfaces/richfaces/blob/master/core/src/main/resource...
{code}
var searchForComponentRootOrReturn = function(sourceElement) {
if (sourceElement.id && !isRichFacesComponent(sourceElement)) {
var parentElement = false;
$(…
[View More]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]*$/) && isRichFacesComponent(this)) {
parentElement = this;
return false;
}
}
});
if (parentElement !== false) {
return parentElement;
}
}
return sourceElement;
};
{code}
We should perhaps take the component separator into account when doing the suffix comparison.
> 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)
[View Less]
10 years, 6 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 edited comment on RF-13776 at 8/13/14 5:34 PM:
---------------------------------------------------------
[~bleathem] yes, I can confirm that changing either the parent or child id to s.th. completely different solves the problem.
But just to make sure: changing the ids of course is a valid workaround, but I think no one can guess that similar ids can lead to such problems, - especially when having no …
[View More]exception, no log, no nothing to work with - except for the fact, that your actionListener is never invoked...
But back to the point, there was s.th. I found during debugging that would support your idea that maybe the relevant code only identifies RichFaces components: when you debug a little further there is that function call to *richfaces.$(sourceElement)* in the code snippet "searchForComponentRootOrReturn" (Note the parameter "sourceElement"!)
Here is the function:
{code:title=richfaces.$|borderStyle=solid}
richfaces.$ = function(source) {
var element = richfaces.getDomElement( source );
if(element)
{
return( element[richfaces.RICH_CONTAINER] || {} )["component"]
}
};
{code}
In the example "source" (and also "element") is the selectBooleanCheckbox which does not have the attribute for "richfaces.RICH_CONTAINER", thus this function returns "undefined", which in turn may lead to the calling function continuing its search for a valid parent.
If I have the next time slot for bug tracing I will also try the two things you mentioned. Meanwhile looking at this function(s) should give you a good starting point for reproducing the problem.
was (Author: michaelb80):
[~bleathem] yes, I can confirm that changing either the parent or child id to s.th. completely different solves the problem.
But just to make sure: changing the ids of course is a valid workaround, but I think no one can guess that similar ids can lead to such problems, - especially when having no exception, no log, no nothing to work with - except for the fact, that your actionListener is never invoked...
But back to the point, there was s.th. I found during debugging that would support your idea that maybe the relevant code only identifies RichFaces components: when you debug a little further there is that function call to *richfaces.$(this)* in the code snippet "searchForComponentRootOrReturn"
Here is the function:
{code:title=richfaces.$|borderStyle=solid}
richfaces.$ = function(source) {
var element = richfaces.getDomElement( source );
if(element)
{
return( element[richfaces.RICH_CONTAINER] || {} )["component"]
}
};
{code}
In the example "source" (and also "element") is the selectBooleanCheckbox which does not have the attribute for "richfaces.RICH_CONTAINER", thus this function returns "undefined", which in turn may lead to the calling function continuing its search for a valid parent.
If I have the next time slot for bug tracing I will also try the two things you mentioned. Meanwhile looking at this function(s) should give you a good starting point for reproducing the problem.
> 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)
[View Less]
10 years, 6 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] yes, I can confirm that changing either the parent or child id to s.th. completely different solves the problem.
But just to make sure: changing the ids of course is a valid workaround, but I think no one can guess that similar ids can lead to such problems, - especially when having no exception, no log, no nothing to work with - …
[View More]except for the fact, that your actionListener is never invoked...
But back to the point, there was s.th. I found during debugging that would support your idea that maybe the relevant code only identifies RichFaces components: when you debug a little further there is that function call to *richfaces.$(this)* in the code snippet "searchForComponentRootOrReturn"
Here is the function:
{code:title=richfaces.$|borderStyle=solid}
richfaces.$ = function(source) {
var element = richfaces.getDomElement( source );
if(element)
{
return( element[richfaces.RICH_CONTAINER] || {} )["component"]
}
};
{code}
In the example "source" (and also "element") is the selectBooleanCheckbox which does not have the attribute for "richfaces.RICH_CONTAINER", thus this function returns "undefined", which in turn may lead to the calling function continuing its search for a valid parent.
If I have the next time slot for bug tracing I will also try the two things you mentioned. Meanwhile looking at this function(s) should give you a good starting point for reproducing the problem.
> 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)
[View Less]
10 years, 6 months