[JBoss JIRA] (RF-13780) Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13780?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13780:
------------------------------------
Thank you for looking into this, I'll see if I can reproduce it. That code you linked however is from jsf.js (i.e. that's not our code) but if we contain the changes to the tree it shouldn't be an issue.
> 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)
9 years, 8 months
[JBoss JIRA] (RF-13719) rich.fileUpload breaks form action in portal
by Ken Finnigan (JIRA)
[ https://issues.jboss.org/browse/RF-13719?page=com.atlassian.jira.plugin.s... ]
Ken Finnigan reassigned RF-13719:
---------------------------------
Assignee: Ken Finnigan
> rich.fileUpload breaks form action in portal
> --------------------------------------------
>
> Key: RF-13719
> URL: https://issues.jboss.org/browse/RF-13719
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: JBoss Portal 6.1.1
> Reporter: Jonáš Trantina
> Assignee: Ken Finnigan
> Labels: gss
> Attachments: reproducer.zip, reproducer2.zip
>
>
> When a rich:fileUpload si submitted (i.e. files are uploaded) action of the form is not preserved well.
> In fileupload.js __submit method there is the following code:
> {code:JavaScript}
> var encodedURLInputs = this.form.children("input[name='javax.faces.encodedURL']");
> var originalAction = encodedURLInputs.length > 0 ? encodedURLInputs.val() : this.form.attr("action");
> {code}
> the var "originalAction" is then used to revert to the original action url of the form. However, encodedURLInputs and form action prop does not contain the same url. Because encodedURLInputs has bigger priority URL from that input is restored into the form and not the original form action. This breaks the form as the next submission fails.
> In portal the solution is
> {code:JavaScript}
> var originalFormAction =this.form.attr("action");
> {code}
> and then restore "originalFormAction" instead of "originalAction", but I am not sure if this doesn't break anything in other environments.
> Is this a bug in richfaces or is the content of input[name='javax.faces.encodedURL'] set badly?
> To reproduce you can use the reproducer attached.
> Example URLs:
> form action
> {code}
> /portal/classic/home/uploadform?portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&interactionstate=JBPNS_rO0ABXcsABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwAB19fRU9GX18*&portal:type=action
> {code}
> input[name='javax.faces.encodedURL']
> {code}
> /portal/classic/home/uploadform?portal:windowState=normal&portal:componentId=834fa198-ff3d-4a5c-a1c7-33c85e8a410d&portal:cacheLevel=PAGE&resourcestate=JBPNS_rO0ABXdAABBfanNmQnJpZGdlVmlld0lkAAAAAQALL2hvbWUueGh0bWwACF9wYnJBamF4AAAAAQAEdHJ1ZQAHX19FT0ZfXw**&portal:type=resource&portal:portletMode=view
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13780) Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
by Michael B (JIRA)
[ 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)
9 years, 8 months
[JBoss JIRA] (RF-13780) Random JavaScript error due to missing attribute 'richfaces.RICH_CONTAINER'
by Michael B (JIRA)
[ https://issues.jboss.org/browse/RF-13780?page=com.atlassian.jira.plugin.s... ]
Michael B commented on RF-13780:
--------------------------------
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)
9 years, 8 months
[JBoss JIRA] (RF-13766) Move classes ElementIsFocused and FocusRetriever to build-resources
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-13766?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-13766:
------------------------------------
[~mtomasek], [~jhuska] please update this issue.
> Move classes ElementIsFocused and FocusRetriever to build-resources
> -------------------------------------------------------------------
>
> Key: RF-13766
> URL: https://issues.jboss.org/browse/RF-13766
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Affects Versions: 4.5.0.Alpha3
> Reporter: Martin Tomasek
> Assignee: Martin Tomasek
> Fix For: 4.5.0.Beta1
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> Move classes ElementIsFocused and FocusRetriever from components/rich/src/test/integration/org/richfaces/components/focus to build/build-resources/src/main/java/org/richfaces/utils.focus package.
> Several showcases tests use these class too. After perform https://issues.jboss.org/browse/RF-12950 showcase tests will be in richfaces repo and they will need use ElementIsFocused and FocusRetriever. Its good to have these two classes in build-resources and not duplicate them.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13785) Validation inside popupPanel is ignored when form is submitted
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13785?page=com.atlassian.jira.plugin.s... ]
Michal Petrov resolved RF-13785.
--------------------------------
Fix Version/s: 4.5.0.Beta1
Resolution: Done
Fixed by forcing {{ExtendedPartialViewContext.getRenderIds()}} to only happen during RenderResponsePhase (and not ApplyRequestValuesPhase). This is how it works in 4.3.7 so it shouldn't break anything.
> Validation inside popupPanel is ignored when form is submitted
> --------------------------------------------------------------
>
> Key: RF-13785
> URL: https://issues.jboss.org/browse/RF-13785
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.5.0.Alpha3, 4.5.0.Beta1
> Reporter: Juraj Húska
> Assignee: Michal Petrov
> Priority: Blocker
> Fix For: 4.5.0.Beta1
>
>
> Consider please a form with multiple inputs inside {{popupPanel}}, which is configured to hide when there are no validation issues.
> *The issue is:* If the form is submitted e.g. with {{a4j:commandButton}}, then it hides even when there are some validation issues.
> {{PopupPanel}} has set {{oncomplete}} attribute to:
> {code:JavaScript}
> oncomplete="if (!#{facesContext.validationFailed}) { #{rich:component('popup')}.hide(); } "
> {code}
> {{facesContext.validationFailed}} is wrongly evaluated always to {{false}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13790) Showcase - dataTable Styling example - broken styling after built in sorting/filtering is enabled
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/RF-13790?page=com.atlassian.jira.plugin.s... ]
Michal Petrov commented on RF-13790:
------------------------------------
We may not want it in the example but if it breaks outside of showcase as well we have to fix it.
I was thinking about using the {{:nth-child()}} pseudo-class/selector but I'm not sure how feasible that is. (It would certainly be easier to leave it on the user).
> Showcase - dataTable Styling example - broken styling after built in sorting/filtering is enabled
> -------------------------------------------------------------------------------------------------
>
> Key: RF-13790
> URL: https://issues.jboss.org/browse/RF-13790
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Beta1
> Reporter: Juraj Húska
> Attachments: dataTableStylingExamplesBroken.png
>
>
> Please checkout the screenshot to see how the styling of the table is broken (every odd row should have different background color).
> There are multiple wrong places in the facelet for this example, which causes this break of styling.
> * code for first column uses attribute {{accept}}, which is not defined for RF4, there should be {{filter}} instead
> * there is typo in EL to reference a bean in the same place, there is {{carsFiteringBean}}, instead of {{carsFilteringBean}}
> * when I change this two things, the filtering does not work either, because in the referenced filter implementation, the {{mileage}} or {{vendor}} is always {{null}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months
[JBoss JIRA] (RF-13790) Showcase - dataTable Styling example - broken styling after built in sorting/filtering is enabled
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13790?page=com.atlassian.jira.plugin.s... ]
Juraj Húska updated RF-13790:
-----------------------------
Attachment: dataTableStylingExamplesBroken.png
> Showcase - dataTable Styling example - broken styling after built in sorting/filtering is enabled
> -------------------------------------------------------------------------------------------------
>
> Key: RF-13790
> URL: https://issues.jboss.org/browse/RF-13790
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: showcase
> Affects Versions: 4.5.0.Beta1
> Reporter: Juraj Húska
> Attachments: dataTableStylingExamplesBroken.png
>
>
> Please checkout the screenshot to see how the styling of the table is broken (every odd row should have different background color).
> There are multiple wrong places in the facelet for this example, which causes this break of styling.
> * code for first column uses attribute {{accept}}, which is not defined for RF4, there should be {{filter}} instead
> * there is typo in EL to reference a bean in the same place, there is {{carsFiteringBean}}, instead of {{carsFilteringBean}}
> * when I change this two things, the filtering does not work either, because in the referenced filter implementation, the {{mileage}} or {{vendor}} is always {{null}}.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 8 months