Section 3.1.4 of the JSF 2.1 Specification says that all attributes of standard components are value expression enabled.
I want to assign a value expression to the action attribute of a commandButton:
<h:commandButton value="OK" action="#{myBean.valExp}" />
I also defined corresponding getValExp and setValExp methods in the bean's class.
However my JSF implementation (JBoss 6) takes that expression to be a method expression and thus yields a "method not found" error because there's no valExp()-method.
Am I doing something wrong or is the specification just too sloppy and actually doesn't mean all, but only the non method expression attributes? Or am I misunderstanding the spec?
[Remark: The reason for this question is no actual technical problem but me trying to understand the difference of value and method expressions.]
Value expressions are bound to properties which are exposed by public getter/setter methods.
<h:inputText value="#{bean.value}" />
This requires public T getValue() and public void setValue(T value) methods. Note that the presence of a private T value; property with literally exactly the same name is not mandatory. In pure output components like <h:outputText>, <h:dataTable>, <f:selectItems>, etc, the setter method is also not mandatory.
Method expressions are bound to non-getter/setter methods ("action" methods).
<h:commandButton value="submit" action="#{bean.submit}" />
This requires a public T submit() method where T can eventually be void and the method can eventually take additional arguments, depending on the attribute's method expression signature. You can read the exact details in the view declaration language documentation, for example the <h:inputText>, <h:commandButton> and <f:ajax> ones. Here's an extract of the action and actionListener attribute definitions of the <h:commandButton>:
Name: action
Type: javax.el.MethodExpression (signature must match java.lang.Object
action())
Description: MethodExpression representing the application action to invoke when
this component is activated by the user. The expression must
evaluate to a public method that takes no parameters, and returns an
Object (the toString() of which is called to derive the logical
outcome) which is passed to the NavigationHandler for this
application.
Name: actionListener
Type: javax.el.MethodExpression (signature must match void
actionListener(javax.faces.event.ActionEvent))
Description: MethodExpression representing an action listener method that will be
notified when this component is activated by the user. The
expression must evaluate to a public method that takes an
ActionEvent parameter, with a return type of void, or to a public
method that takes no arguments with a return type of void. In the
latter case, the method has no way of easily knowing where the event
came from, but this can be useful in cases where a notification is
needed that "some action happened".
Yes, I agree that the spec is somewhat sloppy in stating that all attributes support value expressions. Generally, they actually mean that all attributes support expression language as in #{}. From the other hand on, you can also interpret method expressions as if they are just "special" value expressions, although they are not exactly that. I've posted a spec issue report about this with the request to clear up some confusion: issue 1036.
Related
I've been working with converters in my PrimeFaces SelectOneMenu objects. They work fine if I only tell which class the converter is referring to:
#FacesConverter(forClass = DescriptorVO.class)
public class DescriptorVOConverter implements Converter { ... }
This way, I don't have to explicitly tell the JSF component which converter should be used when it is populated with objects of class DescriptorVO.
However, I made a page that used a p:SelectManyCheckbox and I couldn't for the life of me know why it wasn't calling my converter. Then I gave it a name, like so:
#FacesConverter(forClass = RoleVO.class, value = "roleVOConverter")
public class RoleVOConverter implements Converter { ... }
and passed it as one of the component's properties
<p:selectManyCheckbox id="cbx_roles" required="true" converter="roleVOConverter"
requiredMessage="At least one role must be selected."
value="#{userView.selectedRoles}" layout="responsive">
<f:selectItems value="#{userView.roles}" var="role"
itemLabel="#{role.title}" itemValue="#{role}" />
</p:selectManyCheckbox>
and voi la, it started calling the converter correctly. This raised a question to me regarding when I should name my converters (through the value attribute) and when telling them which class the converter should be used with (with the forClass attribute) is enough. I never had to namy any converters when working with PrimeFaces, only for this particular SelectManyCheckbox component. Do different components have different necessities regarding converters or did I just get the concept of converters wrong?
That can happen when the value of the UISelectMany component references a generic java.util.Collection type like List<Role> instead of an array like Role[]. This is specified in javadoc of UISelectMany (emphasis mine):
Obtain the Converter using the following algorithm:
If the component has an attached Converter, use it.
If not, look for a ValueExpression for value (if any). The ValueExpression must point to something that is:
An array of primitives (such as int[]). Look up the registered by-class Converter for this primitive type.
An array of objects (such as Integer[] or String[]). Look up the registered by-class Converter for the underlying element type.
A java.util.Collection. Do not convert the values.
If for any reason a Converter cannot be found, assume the type to be a String array.
The reason is, the generic type <Role> is lost during runtime and not directly determinable. It works when you're using MyFaces instead of Mojarra as it will in case of a java.util.Collection inspect the actual type by manually iterating over <f:selectItem(s)> and determine the Converter based on first non-null value.
I created spec issue 1422 on this to get this in JSF spec and improve Mojarra too.
See also:
UISelectMany on a List<T> causes java.lang.ClassCastException: java.lang.String cannot be cast to T
Why does JSF put String values in a Map<..., Integer>? And how to work around it?
Use enum in h:selectManyCheckbox
I often face the following problem. I have a JSF application and a facelet where I write EL expressions, like this:
<h:outputText value="#{myBean.foo}">
As long as myBean, as a variable, has a life long enough, there's no problem to evaluate myBean.foo at any given time, but if myBean is a variable that references some bean within a short period of time, when myBean.foo is evaluated it might be too late, so that JSF complains that myBean resolves to null. This is something well-known, but the problem is that it is not clear to me what to expect in different situations.
Concrete example n. 1: if you try the following with PrimeFaces OrderList:
<p:orderList value="#{bean.myValue}" var="item">
<p:column>
<p:commandLink action="#{bean.doSomething(item)}" />
</p:column>
</p:orderList>`
This is not going to work, because when doSomething is called, the item variable is no longer defined (although the object it references is still alive) and hence it's resolved to null. It's a known issue. However the same pattern works fine with <p:dataTable>, for instance. Anyway, I'm not interested right now in this specific problem, I just want to explain my doubt.
Concrete example n. 2: I have written a composite component with a backing bean. The backing bean extends UINamingContainer and uses its StateHelper to retain a model object. This composite allows to write child tags and I would like to write something like this:
<myns:myCc var="myVar">
<h:inputText value="#{myVar.foo}" />
</myns>
With "myVar" I want to give a name to the model object. To make this work, I tried to store the model object in the request map at the beginning of encodeChildren method and remove it afterwards: this works for rendering, but if I then process the input with a commandButton action, it does not work because when the action gets executed it says that myVar can't be resolved: in other words, it tries to resolve the entire expression too late. I then tried to "permanently" save the model object in the view scope map, but it doens't work either. However, if I change this to:
(assuming modelObject is the property field in the backing bean that stores my model object)
it works. So, it is not a problem in my model, but in the way I try to make the model object available to EL expressions for child tags.
Concrete example n. 3: I often use the <ui:param> tag to give beans a shorter name and to ease templating. For instance:
<ui:param name="bean" value="#{longNamedAndPageSpecificBean}" />
So that, in the remainder of the page I can just use #{bean.foo} instead of #{longNamedAndPageSpecificBean.foo}. This works fine even for actions passed to command buttons. However, if I pass a method expression like #{bean.myActionMethod} to a composite component attribute declared with method-signature, when this method expression is actually invoked I receive an error that bean resolves to null... The reason why it works in one case (with commandButton actions) and not in the other (with actions used by the composite component) is a big source of confusion for me.
I would appreciate if someone can help me to understand better this JSF aspect and suggest better approaches/workarounds with the aforementioned concrete examples.
Your question looks too large, but i could say that, during the build time only Session and request scoped values are avaiaible.
The same thing is true for the Execution phase.
Only the render phase should ensure the avaibility of temporal vars "myVar".
The best way to understand what its realy hapening is to debug because its depends on the component implementation
I'm trying to invoke a parameterless method from a JSF 2.0 facelet by
#{myBean.foo()}
(without any surrounding tag).
According to Burns/Schalk: The Complete Reference: JSF 2.0 that's possible (page 126, #{userBean.pullValuesFromFlash( )}).
However the framework takes the expression to be a value expression and thus thinks that foo should be a bean property.
On JBOSS 7.0.1 (and 6, too) I get a
"The class '...' does not have the property 'foo'"
error message.
Judging by this response on the JBoss forum, method expressions must only be used in attributes that support them.
Stan Silvert wrote:
It looks to me like this is working as expected. This has nothing to
do with a lack of arguments. Your expression,
#{elManagedBean.hello()} is being treated as a ValueExpression. If
you changed your method to getHello() then it would work. The
question is, should it be treated as a ValueExpression or a
MethodExpression? For instance, if you had the same expression in an
action attribute it would be treated as a MethodExpression.
<h:commandButton value="Hello" action="#{elManagedBean.hello()}"
id="submit_button"/>
You have put the expression in the middle of
the Facelets page and not as the value of an attribute. As far as I
know, this will always be treated as a ValueExpression. I don't see
how this would work in Glassfish. It's possible that there is some
code that tries it out as a ValueExpression and then tries it as a
MethodExpression if it fails. However, I think that would go against
the EL spec. In other words, I'm surprised that this would work on
Glassfish.
McDowell has answered the cause of the problem: inline expressions are treated as value expressions, not as method expressions.
As to how to achieve the functional requirement anyway, use <f:event>.
<f:event type="preRenderView" listener="#{myBean.foo}" />
This will invoke the method right before render response.
This depends on the EL version you are using on your servlet container. If using Tomcat 6, EL 2.1 is included and this does not support '()' as MethodExpression if the expression is in the middle of the Facelets page. Tomcat 7, which includes EL 2.2 does support this and even enhanced features as being able to pass parameters to the method expression:
So you do this:
<h:outputText value="#{object.test(10)}" ></h:outputText>
And receive the parameter in your bean (extra conversion and validation might be needed):
public String test(MyObject o)
{
...
return value;
}
References:
http://tomcat.apache.org/whichversion.html
Using EL 2.2 with Tomcat 6.0.24
I have a <h:selectBooleanCheckbox value="#{someBean.prop}"> where prop is a property of type int. Is it really not working straight away? Do I have to implement a custom converter to convert Boolean to int? Does anyone happen to have converter code for that at stock? I read that there is some bug in JSF 2.0 that prevents converters for <h:selectBooleanCheckbox> to be processed. Can anyone confirm that?
I use MyFaces 2, Tomahawk and Tomcat 6.
The <h:selectBooleanCheckbox> should, as its name say, be bound to a boolean or Boolean property. Nothing else. That it allows a converter attribute is actually a bug in the spec. It should never have allowed it.
The problem is more in your model, why would you use an int to represent a boolean state? Change your model to let it be a fullworthy boolean.
If changing the model isn't an option for some reason (a 3rd party API, a stupid architect, or stupid business restrictions, etc), then wrap the model getter/setter in the backing bean like follows
public boolean isChecked() {
return someModel.getSomeInt() != 0;
}
public void setChecked(boolean checked) {
someModel.setSomeInt(checked ? 1 : 0);
}
and use it instead as <h:selectBooleanCheckbox value="#{bean.checked}" />.
just to say MySQL doesn't have boolean as field type choice, and it could be an example for this need.
You can set field as tinyint in MySQL. Actually problem is getting method name when you create a boolean variable. Use method name getChecked() instead of isChecked().
I am new to JSF and managed beans. I have a managed bean with some private property with public setter and Getter methods. Now when I add the managed bean's properties to JSF forms, should I add the private methods directly or should I use call the property by Getter methods?
For example:
<h:inputText value="#{BeanName.userName}"/>
<h:inputText value="#{BeanName.getUserName()}"/>
Which one is correct in above?
Assuming that you're using JBoss EL or EL 2.2+, both ways would work fine in the initial display. But the first one is actually more correct because the second one would only get the value, but never set the value. If you want to collect input values, you should always go for the first way. The EL (Expression Language) will then automatically locate the getUserName() and setUserName() methods whenever needed.
The second way will never work when you're using standard JSF EL implementation since it doesn't support direct method calls.
To learn more about JSF, start at our JSF wiki page.
If in your java class you have something like
....
private String coolStuff;
public String getCoolStuff() {
return coolStuff;
}
....
Then in your jsf page you access it like so:
#{myBackingBean.coolStuff}
The framework automatically looks for a method called getCoolStuff()
Hope that helps
number 1 is correct from above it is the private field that you connect if you are using EL with JSF in your form.
You still need the getter and the setter which the managed bean calls to get the values so you can save them in a database ....etc