[
https://issues.apache.org/jira/browse/MYFACES-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14044730#comment-14044730
]
Sven Linstaedt commented on MYFACES-3904:
-----------------------------------------
Hi Leonardo,
the patch does indeed solve the mentioned problem
{code}
<input id="form:shipmentDateCriteriaOption:2" type="radio"
name="form:shipmentDateCriteriaOption" checked="checked"
value="BETWEEN_DATE_RANGE"
onchange="jsf.util.chain(this,event,'$(\'#form\\\\:shipmentDate
:input\').val(\'\')',
'jsf.ajax.request(this,event,{\'javax.faces.behavior.event\':\'valueChange\'})');">
{code}
but beside some failing tests it introduces another problem for f:ajax not
working any more. According to the submitted data for an ajax call:
{code}
javax.faces.behavior.event: valueChange
javax.faces.partial.event: change
javax.faces.source:form: shipmentDateCriteriaOption:2
javax.faces.partial.ajax: true
javax.faces.partial.execute: form:shipmentDateCriteriaOption:2
{code}
there is a mismatch between the submitted javax.faces.partial.execute parameter
and the clientId of the selectOneRadio component, causing the partial execution
of the lifecycle skipping the component at all. If I specify the f:ajax execute
parameter with an explicit clientId of the component, the ajax call works. It
only fails, when execute is set to "@this", which is the default as far as I
remember.
According to the spec, "if options.execute does not exist, create the post data
argument with the name javax.faces.partial.execute and the value as the
identifier of the element that caused this request", which will cause more
complex decoding implementations, but maybe the spec is too vague here or just
simply wrong. I would suggest just using the "name" attribute value of the
event source for filling the javax.faces.partial.execute parameter. wdyt?
> 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)
