myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Lucy <wtl...@us.ibm.com>
Subject Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Date Wed, 20 Aug 2014 18:05:48 GMT

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 <lu4242@gmail.com> wrote on 08/20/2014 01:14:39 PM:

> From: Leonardo Uribe <lu4242@gmail.com>
> To: MyFaces Discussion <users@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 <wtlucy@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
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message