[
https://issues.apache.org/jira/browse/MYFACES-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14117690#comment-14117690
]
Leonardo Uribe commented on MYFACES-3919:
-----------------------------------------
I have checked the patch and I did a small change, just remove the change in
clear hidden fields function name, because in that place the separator is ok. I
did some also some tests and the patch works fine.
Thanks to Bill Lucy for provide this patch.
> 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
> 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)
