myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Commented] (MYFACES-3904) jsf.util.Chain() is rendered with wrong event source
Date Wed, 25 Jun 2014 00:52:27 GMT

    [ https://issues.apache.org/jira/browse/MYFACES-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14042909#comment-14042909
] 

Leonardo Uribe commented on MYFACES-3904:
-----------------------------------------

I have attached a patch for the problem, that replaces the name of the variable targetClientId
with sourceId, which is more appropiate. The patch changes the related methods to allow null
values over the variable and if it is null, use the special "this" keyword, otherwise document.getElementById(...).

I did some tests and it works, but this patch needs to be tested fully before apply it, because
it changes a big portion of the ajax rendering, so it could introduce bugs. The suggestion
is wait to check it until 2.2.5, and apply it only in 2.2.x branch. Then it could be backported
to 2.1.x/2.0.x .

Please try the patch and let us know if it works for your case.

> jsf.util.Chain() is rendered with wrong event source
> ----------------------------------------------------
>
>                 Key: MYFACES-3904
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3904
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Sven Linstaedt
>         Attachments: MYFACES-3904-1.patch
>
>
> When applying multiple behaviors to an component, they are rendered to be executed in
chain by using jsf.util.chain(). So far so good. 
> When applying a behavior to a component, that renders multiple html input elements like
h:selectManyCheckbox or h:selectOneRadio, the javascript is generated for every html elements,
from which everyone gets it's own id rendered by appending a ongoing number to the clientId
of the component. In the myfaces renderer code these Ids are called itemId.
> The problem is, when you apply multiple behaviors to components, which render multiple
html input elements: in this case all behaviors are wrapped in a chained call, which unfortunately
receives not the itemId of the currently rendered html element as the source parameter, but
the clientId of the component. According to the spec, the source parameter should contain
"the DOM element that triggered this Ajax request, or an id string of the element to use as
the triggering element." 
> Because the event handler is bound to the html input element and not to it's parent html
"wrapping" element used for layouting, the wrong event source is rendered in my option, which
leads to the following side effect: Behavior scripts, that reference the current event producing
html element via "this" will receive a different calling context ("this), if chain together
with multiple behaviors than, if they would as single behavior, leading to all behavior scripts
referencing "this" to run in the wrong context and often doing nothing meaningful at all.
> E.g.: chained invocation of 
> {code}
> <input id="form:shipmentDateCriteriaOption:0" type="radio" name="form:shipmentDateCriteriaOption"
value="NEXT_WEEK" onchange="$(this).val('')">
> {code}
> and
> {code}
> <input id="form:shipmentDateCriteriaOption:0" type="radio" name="form:shipmentDateCriteriaOption"
value="NEXT_WEEK" onchange="jsf.ajax.request('form:shipmentDateCriteriaOption',event,{'javax.faces.behavior.event':'valueChange'})">
> {code}
> is rendered as:
> {code}
> <input id="form:shipmentDateCriteriaOption:0" type="radio" name="form:shipmentDateCriteriaOption"
value="NEXT_WEEK" onchange="jsf.util.chain(document.getElementById('form:shipmentDateCriteriaOption'),
event,'$(this).val(\'\')', 'jsf.ajax.request(\'form:shipmentDateCriteriaOption\',event,{\'javax.faces.behavior.event\':\'valueChange\'})');">
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message