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 wtl...@us.ibm.com
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 lu4...@gmail.com wrote on 08/20/2014 01:14:39 PM: From: Leonardo Uribe lu4...@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 wtl...@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 wtl...@us.ibm.com
EL 3.0 Static Field References
Hi All,
I'm running into some issues trying to test the EL 3.0 functionality on
MyFaces 2.2.7 + Tomcat 8.0.16. My understanding is that we should be able
to reference static fields/methods directly from facelets, eg.
Boolean.TRUE test: [h:outputText id=out2
value=#{Boolean.TRUE}/]
should return Boolean.TRUE test: [true]. This isn't the case, however;
no value is returned, and nothing's logged. Additionally, when I try to
access a static field on a local ManagedBean, I get
...
javax.el.PropertyNotFoundException: Property 'staticReference' not
found on type beans.EL30StaticFieldsAndMethodsBean
at javax.el.BeanELResolver$BeanProperties.get
(BeanELResolver.java:244)
at javax.el.BeanELResolver$BeanProperties.access$300
(BeanELResolver.java:221)
at javax.el.BeanELResolver.property(BeanELResolver.java:331)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:95)
at javax.el.CompositeELResolver.getValue
(CompositeELResolver.java:66)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue
(FacesCompositeELResolver.java:179)
... 1 more
Where the ManagedBean is defined simply as
package beans;
import javax.faces.bean.ApplicationScoped;
import javax.faces.bean.ManagedBean;
@ManagedBean(name = staticbean)
@ApplicationScoped
public class EL30StaticFieldsAndMethodsBean {
...
public static final String staticReference = static reference;
...
}
Has anyone else tried working with these kinds of EL 3.0 features? Or am I
possibly just missing something here?
Thanks,
Bill Lucy
Re: EL 3.0 Static Field References
Thanks for the response, Leonardo.
From what I can tell, the issue isn't that MyFaces can't find the
StaticFieldELResolver - that is loaded correctly. JSP static field EL
references do work properly through MyFaces, so there does seem to be some
JSF issue.
I think there may be a spec issue here? (What I believe to be) a similar
issue had to be addressed for JSP 2.3:
https://bz.apache.org/bugzilla/show_bug.cgi?id=57141
MyFaces has a resolver, ScopedAttributeResolver, which always sets the
resolved field on the EvaluationContext to true if the EL expression's
property isn't null. The issue with that is when we're trying to resolve
the EL expression base (eg. Boolean in the expression Boolean.TRUE) EL
3.0 never has a chance to resolve the import the base ELClass, since it
first runs through the EL Resolvers.
My testing has shown that if we don't set context.setPropertyResolved(true)
in the ScopedAttributeResolver, this particular case (#{Boolean.TRUE})
works as expected.
Any thoughts on this? Let me know if I need to clarify anything.
Regards,
Bill Lucy
Leonardo Uribe lu4...@gmail.com wrote on 03/25/2015 06:10:00 PM:
From: Leonardo Uribe lu4...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Date: 03/25/2015 06:11 PM
Subject: Re: EL 3.0 Static Field References
Hi
It is in the spec, it should work.
There is some code in
org.apache.myfaces.el.unified.ResolverBuilderForFaces that deals with
this:
if (STATIC_FIELD_EL_RESOLVER_CLASS != null
GET_STREAM_EL_RESOLVER_METHOD != null)
{
try
{
ELResolver streamElResolver = (ELResolver)
GET_STREAM_EL_RESOLVER_METHOD.invoke(
getRuntimeConfig().getExpressionFactory());
if (streamElResolver != null)
{
// By default return null, but in a EL 3
implementation it should be there,
// this is just to avoid exceptions in junit testing
list.add(streamElResolver);
}
list.add((ELResolver)
STATIC_FIELD_EL_RESOLVER_CLASS.newInstance());
}
The code checks for javax.el.StaticFieldELResolver class and
ExpressionFactory.getStreamELResolver(...) method before
add both EL resolvers.
If MyFaces jars cannot locate these classes, the EL resolvers
are not loaded (because it assumes EL 3.0), and the
described behavior will happen.
regards,
Leonardo Uribe
2015-03-25 15:14 GMT-05:00 William Lucy wtl...@us.ibm.com:
Hi All,
I'm running into some issues trying to test the EL 3.0 functionality on
MyFaces 2.2.7 + Tomcat 8.0.16. My understanding is that we should be
able
to reference static fields/methods directly from facelets, eg.
Boolean.TRUE test: [h:outputText id=out2
value=#{Boolean.TRUE}/]
should return Boolean.TRUE test: [true]. This isn't the case,
however;
no value is returned, and nothing's logged. Additionally, when I try
to
access a static field on a local ManagedBean, I get
...
javax.el.PropertyNotFoundException: Property 'staticReference'
not
found on type beans.EL30StaticFieldsAndMethodsBean
at javax.el.BeanELResolver$BeanProperties.get
(BeanELResolver.java:244)
at javax.el.BeanELResolver$BeanProperties.access$300
(BeanELResolver.java:221)
at javax.el.BeanELResolver.property(BeanELResolver.java:331)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:95)
at javax.el.CompositeELResolver.getValue
(CompositeELResolver.java:66)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue
(FacesCompositeELResolver.java:179)
... 1 more
Where the ManagedBean is defined simply as
package beans;
import javax.faces.bean.ApplicationScoped;
import javax.faces.bean.ManagedBean;
@ManagedBean(name = staticbean)
@ApplicationScoped
public class EL30StaticFieldsAndMethodsBean {
...
public static final String staticReference = static
reference;
...
}
Has anyone else tried working with these kinds of EL 3.0 features? Or
am I
possibly just missing something here?
Thanks,
Bill Lucy
Packaging Flows in Directories Convention
I'm a bit unsure about the validity of a particular flow packaging convention. Consider that we have a flow defined with the following structure: /WEB-INF/flowname/flowname-flow.xml /flowname/flowname.xhtml /flowname/flowname-2.xhtml /flowname/etc. Assuming that no start node is specified in flowname-flow.xml, is this a valid configuration? Currently, MyFaces does not find a start node at all, since it looks for it at /WEB-INF/flowname/flowname.xhtml. Mojarra does parse this configuration without error. The relevant spec is JSF 2.2 11.4.3.3 (Packaging Flows in Directories); there it says: The following conventions apply to flows defined in this manner. Any flow definition in the corresponding -flow.xml file will override any of the conventions in the case of a conflict. Every vdl file in that directory is a view node of that flow. The start node of the flow is the view whose name is the same as the name of the flow. ... Note the ambiguity here - Every vdl file in that directory - which directory? Should MyFaces work with this flow configuration? Thanks, Bill Lucy
Setting the class Attribute for Custom Tags
For native JSF tags, setting the class attribute performs as you'd expect; however, in user-defined tags, setting the class attribute results in the exception java.lang.IllegalArgumentException: Component property class is not writable Which is how we've behaved traditionally; using the styleClass attribute instead does work as expected. Mojarra supports setting the class attribute as of 2.2.9. Additionally, the same issue was fixed in MYFACES-3874 for jsf:class. Would it be worthwhile for us to change the behavior of MyFaces here for custom components - that is, allow them to set a class attribute? (I've tested a change that's fairly trivial, along the lines of the fix in MYFACES-3874). Regards, Bill Lucy wtl...@us.ibm.com
