Forum:

Calling a bean method from JSF.

Ranch Hand

Posts: 179

posted 13 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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

I like...

posted 13 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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

No pain, No gain.
OCJP 1.6, Liferay Certified Developer 6.1

Andreas Svenkson

Ranch Hand

Posts: 179

posted 13 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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

Posts: 28663

211

I like...

posted 13 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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.

Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer

Andreas Svenkson

Ranch Hand

Posts: 179

posted 13 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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
<h:outputText value="#{serviceBean.method}"/>

And that the backing bean would possess
/** * POJO accessor method for the "method" property. * @return "something" */ public String getMethod() { return "something"; }

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

Posts: 28663

211

I like...

posted 13 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

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.

Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.