You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by William Lucy <wt...@us.ibm.com> on 2014/08/20 13:36:36 UTC
Issue with javax.faces.SEPARATOR_CHAR and commandLink
Hello all,
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>
This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. 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.
Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR
use? Thanks for any feedback!
Bill Lucy
IBM RTP WebSphere
wtlucy@us.ibm.com
Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Posted by William Lucy <wt...@us.ibm.com>.
Hi Leonardo,
Thanks for the feedback. I've tested your suggestion, and that seems to
work fine. JIRA issue opened at:
https://issues.apache.org/jira/browse/MYFACES-3919
Regards,
Bill
Leonardo Uribe <lu...@gmail.com> wrote on 08/20/2014 01:14:39 PM:
> From: Leonardo Uribe <lu...@gmail.com>
> To: MyFaces Discussion <us...@myfaces.apache.org>
> Date: 08/20/2014 01:15 PM
> Subject: Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
>
> Hi
>
> 2014-08-20 6:36 GMT-05:00 William Lucy <wt...@us.ibm.com>:
> >
> >
> > Hello all,
> >
> > 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>
> >
> > This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. 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.)
>
> Yes, that's the reason why we remove it. It was legacy stuff from 1.1/1.2
and
> with 2.2 it is the right time to do a cleanup in the codebase.
>
> > 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.
> >
> > Is this a bug, or just an accepted limitation of
javax.faces.SEPARATOR_CHAR
> > use? Thanks for any feedback!
> >
>
> It is a bug. 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. Please create an issue in MyFaces issue tracker and I'll fix it on
all
> affected branches.
>
> https://issues.apache.org/jira/browse/MYFACES
>
> regards,
>
> Leonardo Uribe
>
> > Bill Lucy
> > IBM RTP WebSphere
> > wtlucy@us.ibm.com
>
Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
2014-08-20 6:36 GMT-05:00 William Lucy <wt...@us.ibm.com>:
>
>
> Hello all,
>
> 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>
>
> This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4. 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.)
Yes, that's the reason why we remove it. It was legacy stuff from 1.1/1.2 and
with 2.2 it is the right time to do a cleanup in the codebase.
> 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.
>
> Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR
> use? Thanks for any feedback!
>
It is a bug. 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. Please create an issue in MyFaces issue tracker and I'll fix it on all
affected branches.
https://issues.apache.org/jira/browse/MYFACES
regards,
Leonardo Uribe
> Bill Lucy
> IBM RTP WebSphere
> wtlucy@us.ibm.com