File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Calling a bean method from JSF.

 
Andreas Svenkson
Ranch Hand
Posts: 179
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 171
Java Linux Spring
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you please try without "()" as post fix in your method name? Like <hutputText value="#{serviceBean.method}"/>
 
Andreas Svenkson
Ranch Hand
Posts: 179
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 17639
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Andreas Svenkson
Ranch Hand
Posts: 179
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 17639
39
Android Eclipse IDE Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic