[jira] [Commented] (MYFACES-3904) jsf.util.Chain() is rendered with wrong event source
[
https://issues.apache.org/jira/browse/MYFACES-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[VOTE] Release of MyFaces Core 2.2.4
Hi, I was running the needed tasks to get the 2.2.4 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.3 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1026/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces224binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326802
Re: [VOTE] Release of MyFaces Core 2.2.4
+1 2014-06-26 11:52 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.2.4 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.3 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1026/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces224binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326802
[jira] [Updated] (TRINIDAD-2487) NoSuchElementException in UIXIterator.visitData (Issue #2)
[ https://issues.apache.org/jira/browse/TRINIDAD-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabrielle Crawford updated TRINIDAD-2487: - Resolution: Fixed Fix Version/s: 2.1.1-core Status: Resolved (was: Patch Available) At revision: 1605854 NoSuchElementException in UIXIterator.visitData (Issue #2) -- Key: TRINIDAD-2487 URL: https://issues.apache.org/jira/browse/TRINIDAD-2487 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Environment: this is environment independent. Reporter: Leon Chan Assignee: Gabrielle Crawford Fix For: 2.1.1-core Attachments: JIRA-2487-trunk.patch When TRINIDAD-2477 was fixed, an existing null pointer check was removed. While it is unknown if it will cause problem in practice, it is a change of behavior in some situations that is not intentional. To minimize the risk of introducing regression, an additional patch is provided to add back the null pointer check. This should be applied on top of the fix to TRINIDAD-2477. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release of MyFaces Core 2.2.4
+1 Am 26.06.14 18:52, schrieb Leonardo Uribe: +1 2014-06-26 11:52 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.2.4 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.3 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1026/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces224binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326802
[jira] [Created] (TRINIDAD-2488) NPE in TrinidadSkinProvider when base skin is not included in skin def in trinidad-skins.xml
Prakash Udupa created TRINIDAD-2488: --- Summary: NPE in TrinidadSkinProvider when base skin is not included in skin def in trinidad-skins.xml Key: TRINIDAD-2488 URL: https://issues.apache.org/jira/browse/TRINIDAD-2488 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Prakash Udupa In our application, we encountered this NPE, whenever base skin is not mentioned in the skin definition in trinidad-skins.xml (trivial to build a test-case thus). This needs to be fixed, because Trinidad framework is supposed to assume the default base skin based on renderkit or otherwise default to Trinidad's simple.desktop skin. == # java.lang.NullPointerException #at org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider.loadAvailableSkin(TrinidadSkinProvider.java:163) #at org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider._getMatchingSkin(BaseSkinProvider.java:216) #at org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider.getSkin(BaseSkinProvider.java:60) #at org.apache.myfaces.trinidadinternal.skin.provider.SkinProviderRegistry.getSkin(SkinProviderRegistry.java:116) #at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext._initializeSkin(CoreRenderingContext.java:635) #at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.init(CoreRenderingContext.java:89) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TRINIDAD-2488) NPE in TrinidadSkinProvider when base skin is not included in skin def in trinidad-skins.xml
[ https://issues.apache.org/jira/browse/TRINIDAD-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash Udupa updated TRINIDAD-2488: Status: Patch Available (was: Open) NPE in TrinidadSkinProvider when base skin is not included in skin def in trinidad-skins.xml Key: TRINIDAD-2488 URL: https://issues.apache.org/jira/browse/TRINIDAD-2488 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 2.1.0-core Reporter: Prakash Udupa Attachments: TRINIDAD-2488.trunk.patch Original Estimate: 1h Remaining Estimate: 1h In our application, we encountered this NPE, whenever base skin is not mentioned in the skin definition in trinidad-skins.xml (trivial to build a test-case thus). This needs to be fixed, because Trinidad framework is supposed to assume the default base skin based on renderkit or otherwise default to Trinidad's simple.desktop skin. == # java.lang.NullPointerException # at org.apache.myfaces.trinidadinternal.skin.provider.TrinidadSkinProvider.loadAvailableSkin(TrinidadSkinProvider.java:163) # at org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider._getMatchingSkin(BaseSkinProvider.java:216) # at org.apache.myfaces.trinidadinternal.skin.provider.BaseSkinProvider.getSkin(BaseSkinProvider.java:60) # at org.apache.myfaces.trinidadinternal.skin.provider.SkinProviderRegistry.getSkin(SkinProviderRegistry.java:116) # at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext._initializeSkin(CoreRenderingContext.java:635) # at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.init(CoreRenderingContext.java:89) -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release of MyFaces Core 2.2.4
+1 On Thu, Jun 26, 2014 at 11:03 AM, Werner Punz werner.p...@gmail.com wrote: +1 Am 26.06.14 18:52, schrieb Leonardo Uribe: +1 2014-06-26 11:52 GMT-05:00 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.2.4 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.2.3 [1] 2. Maven artifact group org.apache.myfaces.core v2.2.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.2.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/ orgapachemyfaces-1026/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces224binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa? projectId=10600version=12326802 -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[ANNOUNCE] Release of Apache MyFaces Extensions Validator 2.0.8
The Apache MyFaces team is pleased to announce the 8th release of Apache MyFaces Extensions Validator (for JSF 2.x). Apache MyFaces Extensions Validator is an extensible framework to validate user input based on annotations. The release contains several improvements. Apache MyFaces Extensions Validator is available in both binary and source distributions: http://myfaces.apache.org/extensions/validator/download.html Apache MyFaces Extensions Validator is available in the central Maven repository under Group ID org.apache.myfaces.extensions.validator.*. Release Notes: http://s.apache.org/EXTVAL_208 Enjoy! Gerhard Petracek
[jira] [Created] (TRINIDAD-2489) Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
Naizam Olakara created TRINIDAD-2489:
Summary: Incorrect filename displayed in Chrome while using
FILEDOWNLOADACTIONLISTENER
Key: TRINIDAD-2489
URL: https://issues.apache.org/jira/browse/TRINIDAD-2489
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Naizam Olakara
Priority: Minor
When using the fileDownloadActionListener, if the filename has a comma (,)
chrome will show the comma as %2C. Firefox and IE work fine.
Create a page with filedownload action listener like below
tr:commandLink immediate=true text=Command Link
tr:fileDownloadActionListener contentType=text/plain
filename=526,1.zip method=#{fileDownload.sendHelloFile}/
/tr:commandLink
Sample file name is, 526,1.zip
In firefox and IE, the filename will be displayed as 526,1.zip. In chrome it
will be 526%2C1.zip.
Fix:-
src\main\java\org\apache\myfaces\trinidadinternal\taglib\listener\FileDownloadActionListener.java
Here, the filename is encoded differently based on browsers. Currently IE and
all webkit browsers has UTF-8 URL encoding and others (gecko) have UTF-8
quoted-printable encoding. Chrome also needs UTF-8 quoted-printable encoding. A
check is added to handle this case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2489) Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
[
https://issues.apache.org/jira/browse/TRINIDAD-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naizam Olakara updated TRINIDAD-2489:
-
Status: Patch Available (was: Open)
Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
-
Key: TRINIDAD-2489
URL: https://issues.apache.org/jira/browse/TRINIDAD-2489
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Naizam Olakara
Priority: Minor
When using the fileDownloadActionListener, if the filename has a comma (,)
chrome will show the comma as %2C. Firefox and IE work fine.
Create a page with filedownload action listener like below
tr:commandLink immediate=true text=Command Link
tr:fileDownloadActionListener contentType=text/plain
filename=526,1.zip method=#{fileDownload.sendHelloFile}/
/tr:commandLink
Sample file name is, 526,1.zip
In firefox and IE, the filename will be displayed as 526,1.zip. In chrome
it will be 526%2C1.zip.
Fix:-
src\main\java\org\apache\myfaces\trinidadinternal\taglib\listener\FileDownloadActionListener.java
Here, the filename is encoded differently based on browsers. Currently IE and
all webkit browsers has UTF-8 URL encoding and others (gecko) have UTF-8
quoted-printable encoding. Chrome also needs UTF-8 quoted-printable encoding.
A check is added to handle this case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2489) Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
[
https://issues.apache.org/jira/browse/TRINIDAD-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naizam Olakara updated TRINIDAD-2489:
-
Status: Open (was: Patch Available)
Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
-
Key: TRINIDAD-2489
URL: https://issues.apache.org/jira/browse/TRINIDAD-2489
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Naizam Olakara
Priority: Minor
When using the fileDownloadActionListener, if the filename has a comma (,)
chrome will show the comma as %2C. Firefox and IE work fine.
Create a page with filedownload action listener like below
tr:commandLink immediate=true text=Command Link
tr:fileDownloadActionListener contentType=text/plain
filename=526,1.zip method=#{fileDownload.sendHelloFile}/
/tr:commandLink
Sample file name is, 526,1.zip
In firefox and IE, the filename will be displayed as 526,1.zip. In chrome
it will be 526%2C1.zip.
Fix:-
src\main\java\org\apache\myfaces\trinidadinternal\taglib\listener\FileDownloadActionListener.java
Here, the filename is encoded differently based on browsers. Currently IE and
all webkit browsers has UTF-8 URL encoding and others (gecko) have UTF-8
quoted-printable encoding. Chrome also needs UTF-8 quoted-printable encoding.
A check is added to handle this case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TRINIDAD-2489) Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
[
https://issues.apache.org/jira/browse/TRINIDAD-2489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naizam Olakara updated TRINIDAD-2489:
-
Status: Patch Available (was: Open)
Incorrect filename displayed in Chrome while using FILEDOWNLOADACTIONLISTENER
-
Key: TRINIDAD-2489
URL: https://issues.apache.org/jira/browse/TRINIDAD-2489
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Naizam Olakara
Priority: Minor
Attachments: trunk.patch
When using the fileDownloadActionListener, if the filename has a comma (,)
chrome will show the comma as %2C. Firefox and IE work fine.
Create a page with filedownload action listener like below
tr:commandLink immediate=true text=Command Link
tr:fileDownloadActionListener contentType=text/plain
filename=526,1.zip method=#{fileDownload.sendHelloFile}/
/tr:commandLink
Sample file name is, 526,1.zip
In firefox and IE, the filename will be displayed as 526,1.zip. In chrome
it will be 526%2C1.zip.
Fix:-
src\main\java\org\apache\myfaces\trinidadinternal\taglib\listener\FileDownloadActionListener.java
Here, the filename is encoded differently based on browsers. Currently IE and
all webkit browsers has UTF-8 URL encoding and others (gecko) have UTF-8
quoted-printable encoding. Chrome also needs UTF-8 quoted-printable encoding.
A check is added to handle this case.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (MYFACES-3904) jsf.util.Chain() is rendered with wrong event source
[
https://issues.apache.org/jira/browse/MYFACES-3904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14045397#comment-14045397
]
Leonardo Uribe commented on MYFACES-3904:
-
Now I can remember the problem and why we decided to send always the clientId
of the component as source attribute.
The problem is the 'source' attribute can be any id, but there is no way to do
properly the mapping between the id and the component.
This is done usually with the clientId, so only if the clientId is added in
this location, the mapping can be done and then the decoding will work
properly.
But in this case, the source of the function jsf.util.chain(...) is used to
for something else. In this case, this field is used to define the context of
the method.
The clientId is an unique identifier that binds the UIComponent instance and a
DOM element in the html markup tree. Use some other id in source field
doesn't make any sense in the server side.
JSF 2.0 section 14.2.3 says this:
...Values for the execute and render attributes are not required. When using
the JavaScript API, the default values for execute is @this. The default value
for render is @none. ...
And then it says that:
jsf.ajax.request(this,event);
is the same as:
jsf.ajax.request(this,event,{execute:’@this’,render:’@this’});
This works well because the ajax is always added in the top HTML element that
has as id the clientId of the component that has the behavior attached. But in
the case of h:selectManyCheckbox for example, we do not have that case, but the
code doesn't have any idea about where this is rendered.
How the f:ajax behavior can know where it is rendered? When
ClientBehaviorContext.createClientBehaviorContext(...) is called, the sourceId
is passed too.
This is what the javadoc of ClientBehaviorContext.getSourceId() says:
... Returns an id for use as the ClientBehavior source. ClientBehavior
implementations that submit back to the Faces lifecycle are required to
identify which component triggered the ClientBehavior-initiated request via the
javax.faces.source request parameter. In most cases, th source id can be
trivially derived from the element to which the behavior's client-side script
is attached - ie. the source id is typically the id of this element. However,
in components which produce more complex content, the behavior script may not
be able to determine the correct id to use for the javax.faces.source value.
The getSourceId() method allows the component to pass this information into the
ClientBehavior.getScript(javax.faces.component.behavior.ClientBehaviorContext)
implementation. ...
Then it says this:
...return the id for the behavior's script to use as the source, or null if
the Behavior's script can identify the source from the DOM. ...
So, there is a confusion between the value that pass javax.faces.source and the
values that javax.faces.partial.execute has.
Additionally, it looks like the source field of jsf.util.chain(...) is
special and is not the same as the one used in jsf.ajax.request(...). Why?
because in jsf.util.chain(...) source has the purpose of define the context,
so when the methods are called, this can be properly set.
The easiest fix I can imagine is do not use targetClientId or the sourceId in
jsf.util.chain(...) and use this instead, but do not change anything else. It
is not pretty, but I think it is justified. I can't imagine another case when
jsf.util.chain use other different value as this.
There is still the chance to fix the renderers, so they can use this instead
document.getElementById(...). That will reduce the amount of rendered
javascript, but the effort is too high, because we need to update the current
logic we have in the renderer code, and do that will introduce new bugs. Maybe
it could be done for 2.2.x.
Let us know if the patch proposed fix the problem and if that so, I'll commit
it. I know the patch doesn't fix the problem fully, but it is the best option
so far, and it has passed a long time since 2.0 until someone detected it. So,
this bug is not very relevant, it has an easy fix, it is difficult to solve,
the probability of introduce new bugs is too high.
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
