Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
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 wrote on 08/20/2014 01:14:39 PM: > From: Leonardo Uribe > To: MyFaces Discussion > 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 : > > > > > > 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): > > > > > > > > > > > > > > > > > > > > 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 > > wtl...@us.ibm.com >
Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink
Hi 2014-08-20 6:36 GMT-05:00 William Lucy : > > > 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): > > > > > > > > > > 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 > wtl...@us.ibm.com
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): 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 wtl...@us.ibm.com
