You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2014/09/01 22:40:21 UTC
[jira] [Updated] (MYFACES-3919) javax.faces.SEPARATOR_CHAR Applied
Incorrectly to commandLink Hidden Field
[ https://issues.apache.org/jira/browse/MYFACES-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leonardo Uribe updated MYFACES-3919:
------------------------------------
Resolution: Fixed
Fix Version/s: 2.2.5
2.1.16
2.0.22
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
> javax.faces.SEPARATOR_CHAR Applied Incorrectly to commandLink Hidden Field
> --------------------------------------------------------------------------
>
> Key: MYFACES-3919
> URL: https://issues.apache.org/jira/browse/MYFACES-3919
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.21, 2.1.15, 2.2.4
> Environment: WebSphere 8.5.5
> Reporter: Bill Lucy
> Assignee: Leonardo Uribe
> Fix For: 2.0.22, 2.1.16, 2.2.5
>
> Attachments: myfaces-3919-2.0.21.patch
>
>
> We've come across an issue while trying to modify the javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to break h:commandLink actions. For example, with the separator character set to a hyphen "-", the following navigation does not work (the output link just triggers a refresh):
> <f:view>
> <h:form>
> <h:commandLink id="link" action="toLink.html">
> <h:outputText value="Link" />
> </h:commandLink>
> </h:form>
> </f:view>
> A workaround is to enable the context parameter org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter has been removed in the 2.2 branch. (It's also not a particularly desirable workaround.) The issue here seems to stem from the oamSubmit.js script; in that file there is a call
>
> myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId);
>
> which explicitly passes uses a colon separator character. In HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have
>
> return formInfo.getFormName() + UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME;
>
> which will cause the wrong hidden field name to be searched, and the broken actions seen here.
> As suggested by Leonardo:
> We should not use UINamingContainer.getSeparatorChar(...) to
> render that hidden field and enforce ':' instead. The reason is the intention
> of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css
> when you use the ':', but in this case the intention is to create a hidden
> field, with no real underlying component, so it is better to let ':' on the js
> file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)