permaculture playing cards*
The moose likes JSF and the fly likes Calling a bean method from JSF. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Calling a bean method from JSF." Watch "Calling a bean method from JSF." New topic
Author

Calling a bean method from JSF.

Andreas Svenkson
Ranch Hand

Joined: Jan 17, 2011
Posts: 179
Hi guys.

I'm currently working on a webapplication that will be implemented using JSF and JBoss.

Having previously used the latest version of JBoss (7.1.1 Final), I was perfectly able to call a method in jsf using this code:



The ServiceBean class looking like this:



The problem is this.... using JBoss version 7.1.1 Final, this works fine. But when I try to deploy the same application in JBoss 7.0.2 Final, i get the following error:

javax.servlet.ServletException: /pages/persons.xhtml @13,50 value="#{serviceBean.method()}": The class 'com.apper.soda.ejb.ServiceBean$Proxy$_$$_Weld$Proxy$' does not have the property 'method'.


Does anyone have an idea why this code might work on 7.1.1 and not 7.0.2 ?

Thanks,
Andreas.
Kumaravadivel Subramani
Ranch Hand

Joined: Jul 05, 2008
Posts: 166

Can you please try without "()" as post fix in your method name? Like <hutputText value="#{serviceBean.method}"/>


No pain, No gain.
OCJP 1.6
Andreas Svenkson
Ranch Hand

Joined: Jan 17, 2011
Posts: 179
Hi, thanks for answering.

Yeah, I've tried that too, I get the same inexplicable error:

javax.servlet.ServletException: /listperson.xhtml @13,47 value="#{serviceBean.method}": The class 'se.apper.soda.ejb.ServiceBean$Proxy$_$$_Weld$Proxy$' does not have the property 'method'.


I'm really very puzzled to why this is working with 7.1 and not 7.0.

// Andreas
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

The problem is more like "why did it ever work at all?"

The JSF View Definition Language (VDL) is not a programming language. It is a specification language that defines a View template. Although you can code simple expressions using EL, they should be limited to things that control how the view displays. Using EL to code application logic (business logic) is a violation of the MVC paradigm which makes it more expensive to maintain apps and is a right royal to debug on top of that.

The "value" attribute that appears on most of the JSF HTML data controls is NOT a method "call". It is a reference[/b] to a backing bean [i]property. A data value, not a function. According the the JavaBean convention, that means that there should be public "get" and "set" accessor methods defined in the backing bean ("set" is optional when you're using a display-only control such as outputText).

What that means is that what JSF is expecting is that you'd code


And that the backing bean would possess


Which I don't think is what you wanted, but it's what JSF wants.

Customer surveys are for companies who didn't pay proper attention to begin with.
Andreas Svenkson
Ranch Hand

Joined: Jan 17, 2011
Posts: 179
Tim Holloway wrote:The problem is more like "why did it ever work at all?"

The JSF View Definition Language (VDL) is not a programming language. It is a specification language that defines a View template. Although you can code simple expressions using EL, they should be limited to things that control how the view displays. Using EL to code application logic (business logic) is a violation of the MVC paradigm which makes it more expensive to maintain apps and is a right royal to debug on top of that.

The "value" attribute that appears on most of the JSF HTML data controls is NOT a method "call". It is a reference[/b] to a backing bean [i]property. A data value, not a function. According the the JavaBean convention, that means that there should be public "get" and "set" accessor methods defined in the backing bean ("set" is optional when you're using a display-only control such as outputText).

What that means is that what JSF is expecting is that you'd code


And that the backing bean would possess


Which I don't think is what you wanted, but it's what JSF wants.


Yes, I'm very well aware of this. And while adding two methods called setMethod() and getMethod(), we can "trick" (more like, tell) JSF that the backing bean has a property called 'method', and therefor can be reached by: #{backingBean.method}.

This is all fine, the only thing I am pointing out here, is that with a newer version of JBoss, we can explicitly input the return value of a backing bean method, without having to go through the "hassle" of craeting getX() and setX() with appropriate names. We can just name the method anything we like, and then reach it from JSF like I wrote earlier.

Obviously, it's not a big deal. I would guess that JSF (or the JBoss implementation of it, to be exact, maybe others too though?) simply added this functionality in a later release than 7.0.2, which is why it's not working in 7.0.2, but working fine in 7.1.1. I was just curious to know if anyone else found it peculiar.

// Andreas
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15665
    
  15

In JSF1, values and methods could not be parameterized. JSF2 added support for parameters, but personally, I try to avoid them. I haven't checked the JBoss specs lately, but it's possible that that's where the difference lies.

In most cases, parameters on view elements mean that the MVC paradigm is being corrupted, and while I'm not a big fan of ideological purity, the main reason for keeping anything even remotely resembling logic off of the View is that when maintenance time comes, I prefer to have one and only one place to look for logic changes, and that's the backing bean. Otherwise it turns into a "treasure hunt" looking for the affected elements, plus the tighter coupling between View and Model means that more things can break in strange and unpredictable ways. In pure MVC terms, there's also the matter that it should be possible to open multiple Views of the same Model and get consistent results and that's at risk when the View gets too involved with the logic.

JSF is architected with the idea that most of the "heavy lifting" is done on the server side, behind the scenes and using Inversion of Control techniques. Which is to say, by internal manipulation of the Model. Client-side parameters are often a red flag that someone's trying to use a hammer on JSF to make it work more like what they're used to.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Calling a bean method from JSF.
 
Similar Threads
First Cup: Java EE Tutorial
Bean value not maintained in RequestScoped
JSF 2.0 Login
Trying to change <ui:include> src tag dinamically
Problem achieving masterpage functionality in JSF