[
https://issues.jboss.org/browse/RF-13780?page=com.atlassian.jira.plugin.s...
]
Michael B edited comment on RF-13780 at 8/19/14 11:18 AM:
----------------------------------------------------------
One more day later of debugging I've found the problem. It's the same problem with
RF which already took us days and several workarounds during the past weeks: the partial
response handling of RF...
So here's the explanation:
In a complex page layout using lots of conditional rendering via AJAX or native RF
components like togglePanel with mode "ajax", there are DOM elements which are
not visible. If you miss to add limitRender="true" on every AJAX request (or if
it's ignored like in the case of rich:tree - arghhh...), there are updates to
invisible components in the partial response. For example for rich:message/s or other
elements which are rendered on AJAX requests per default or elements with
ajaxRendered="true".
Having to add limitRender="true" to each and every AJAX request in the project
is our workaround for similar behavior at several places! - which of course produces other
side effects...
So in our page layout there are collapsed toggle panels which contain several
rich:message. The AJAX request that is sent by toggling the tree omits the workaround with
limitRender="true" and produces updates to invisible components. The reason why
the problem is so hard to reproduce is, that the order of update elements in the partial
response is arbitrary!! So if in our case the update to the toggled tree node is processed
*before* any update to an invisible component (which fails), expanding the tree works. If
however a hidden element is to be updated first, the update processing stops, omitting the
rest of the updates, the tree is not expanded, and the entire application stops working.
Here is the RF code that evaluates the partial response updates:
{code:title=response: function response(request, context)}...
try {
for (var i = 0; i < changes.length; i++) {
switch (changes[i].nodeName) {
case "update":
doUpdate(changes[i], context);
break;
case "delete":
doDelete(changes[i]);
break;
case "insert":
doInsert(changes[i]);
break;
case "attributes":
doAttributes(changes[i]);
break;
case "eval":
doEval(changes[i]);
break;
case "extension":
// no action
break;
default:
sendError(request, context, "malformedXML",
"Changes allowed are: update, delete, insert, attributes, eval, extension. Received
" + changes[i].nodeName + " instead.");
return;
}
}
} catch (ex) {
sendError(request, context, "malformedXML", ex.message);
return;
}
sendEvent(request, context, "success");
{code}
The for-loop iterates over all updates in the partial response and if one fails, the
entire loop breaks. For some reason I havn't looked into, the sendError is swallowed
at some point, so there is no output of that error to a4j:log in some cases like our
complex page. - In other pages we found the problem and the need for
limitRender="true" with a4j:log.
It would be fine, if the loop continued or invisible elements are ignored during the
update. But currently one failed update breaks the entire application.
*Could you please raise this bug to a blocker and also fix rich:tree not respecting
limitRender="true", because without it, there is not even a workaround!*
If you need any arguments to why this is a blocker, let me say it again: that behavior
took us days on several occasions.
was (Author: michaelb80):
One more day later of debugging I've found the problem. It's the same problem with
RF which already took us days and several workarounds during the past weeks: the partial
response handling of RF...
So here's the explanation:
In a complex page layout using lots of conditional rendering via AJAX or native RF
compontents like togglePanel with mode "ajax", there are DOM elements which are
not visible. If you miss to add limitRender="true" on every AJAX request (or if
it's ignored like in the case of rich:tree - arghhh...), there are updates to
invisible components in the partial response. For example for rich:message/s or other
elements which are rendered on AJAX requests per default or elements with
ajaxRendered="true".
Having to add limitRender="true" to each and every AJAX request in the project
is our workaround for similar behavior at several places! - which of course produces other
side effects...
So in our page layout there are collapsed toggle panels which contain several
rich:message. The AJAX request that is sent by toggling the tree omits the workaround with
limitRender="true" and produces updates to invisible components. The reason why
the problem is so hard to reproduce is, that the order of update elements in the partial
response is arbitrary!! So if in our case the update to the toggled tree node is processed
*before* any update to an invisible component (which fails), expanding the tree works. If
however a hidden element is to be updated first, the update processing stops, omitting the
rest of the updates, the tree is not expanded, and the entire application stops working.
Here is the RF code that evaluates the partial response updates:
{code:title=response: function response(request, context)}...
try {
for (var i = 0; i < changes.length; i++) {
switch (changes[i].nodeName) {
case "update":
doUpdate(changes[i], context);
break;
case "delete":
doDelete(changes[i]);
break;
case "insert":
doInsert(changes[i]);
break;
case "attributes":
doAttributes(changes[i]);
break;
case "eval":
doEval(changes[i]);
break;
case "extension":
// no action
break;
default:
sendError(request, context, "malformedXML",
"Changes allowed are: update, delete, insert, attributes, eval, extension. Received
" + changes[i].nodeName + " instead.");
return;
}
}
} catch (ex) {
sendError(request, context, "malformedXML", ex.message);
return;
}
sendEvent(request, context, "success");
{code}
The for-loop iterates over all updates in the partial response and if one fails, the
entire loop breaks. For some reason I havn't looked into, the sendError is swallowed
at some point, so there is no output of that error to a4j:log in some cases like our
complex page. - In other pages we found the problem and the need for
limitRender="true" with a4j:log.
It would be fine, if the loop continued or invisible elements are ignored during the
update. But currently one failed update breaks the entire application.
*Could you please raise this bug to a blocker and also fix rich:tree not respecting
limitRender="true", because without it, there is not even a workaround!*
If you need any arguments to why this is a blocker, let me say it again: that behavior
took us days on several occasions.
Random JavaScript error due to missing attribute
'richfaces.RICH_CONTAINER'
---------------------------------------------------------------------------
Key: RF-13780
URL:
https://issues.jboss.org/browse/RF-13780
Project: RichFaces
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: component, component-tree
Affects Versions: 4.3.7
Environment: RichFaces 4.3.7
Mojarra 2.1.29
Java 7 Update 67 (x64)
Tomcat 7.0.52 (x64)
Firefox 31
Reporter: Michael B
First of all: this is a bug report which may be related to RF-13776, since it also
originates in the same spot of the JavaScript library of RichFaces.
Preface:
The problem is difficult to reproduce systematically, since it only seems to occur in one
of n cases of loading one and the same complex xhtml (with exactly the same data from the
backing bean).
The problem is described based on the rich:tree component when clicking on the expand
icon of a treeNode which fires a "ToggleEvent".
Occasionally there is a JavaScript error in the last line of
{code}
richfaces.ui.TreeNode.emitToggleEvent = function(nodeId) {
var node = document.getElementById(nodeId);
if (!node) {
return;
}
richfaces.$(node).__fireToggleEvent();
};
{code}
When the problem occurs, the expression {code}richfaces.$(node){code} evaluates to
'undefined'.
Debugging into the function when the problem occurs:
{code:title=richfaces.$|borderStyle=solid}
richfaces.$ = function(source) {
var element = richfaces.getDomElement( source );
if(element)
{
return( element[richfaces.RICH_CONTAINER] || {} )["component"]
}
};
{code}
While the element is correctly evaluated to the treeNode/treeNodeToggle-source, the
expression {code}element[richfaces.RICH_CONTAINER]{code} evaluates to
'undefined'.
Reloading the page one or more times produces correct results, where the attribute is
set.
To be able to provide a reproducable example of the problem, please provide some
information under which circumstances the property may not be set correctly for some
components. Please also give us a hint, where to debug into the RF JavaScript code to find
the spot where this property is set.
Although the problem doesn't occur all the time, it happens quite often with the
effect of breaking the entire application. So for future versions I would suggest a check
if {code}richfaces.$(xyz){code} evalutes to a valid result, before invoking any operations
on the result and maybe write a message to the a4j:log in cases where a valid result is
expected but not returned.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)