wood burning stoves 2.0*
The moose likes JSF and the fly likes JSF 1.2 passing parameter to Managed Bean method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "JSF 1.2 passing parameter to Managed Bean method" Watch "JSF 1.2 passing parameter to Managed Bean method" New topic
Author

JSF 1.2 passing parameter to Managed Bean method

Sushma Sharma
Ranch Hand

Joined: Jun 02, 2005
Posts: 139
Hi,
Can anyone please tell me how to pass a parameter from EL expression to Managed Bean method? I am using jsf1.2, facelets. I read somewhere that there is a standard way to do it in JSF 1.2. I have done it in jsf1.1, but had to create my own implementation of HashMap. If there is something already out there, then I would like to avoid doing that in JSF 1.2.

in other words I want to do this :


Thanks in advance,
Sushma
Akaine Harga
Ranch Hand

Joined: Nov 03, 2009
Posts: 79

As far as know EL doesn't allow this.

This short article shows very well how to pass parameters to bean properties from the front with just JSF and by using different JSF sub-frameworks: http://www.therichwebexperience.com/blog/max_katz/2009/02/how_to_delete_a_row_in_jsf


Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
willCodeForFood("Java,PHP,C#,XML,VBS,XHTML,CSS,JavaScript,SQL"); //always looking for job opportunities in AU/NZ/US/CA/Europe :P
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

Although JSF backing beans (Managed beans) are generic JavaBeans, the JSF contract only admits to 3 kinds of methods for them:

1. Property methods (setters/getters)

2. Action processors

3. Listeners

Any methods not adhering to one of these 3 patterns may be employed by non-JSF services, but JSF won't know what to do with them.

Generic method calls are not part of the architecture and have nowhere to fit in the JSF lifecycle. That's problem #1.

EL is supposed to be an "Expression Language" and not a general-purpose programming language. That's problem #2.

Your actual sample syntax resembles how one would use a property representing a Map. Except that in that case the actual EL would be in the form "bean.testdata[itemId]".


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

Joined: Jun 02, 2005
Posts: 139
This MyFaces wiki http://wiki.apache.org/myfaces/Parameters_In_EL_Functions says that with Facelets or JSF 1.2 there is a standard way to make static java methods callable from EL , but doesn't describe it how. It shows how to do it for jsf1.1, which I already know.
also this link on facelets https://facelets.dev.java.net/nonav/docs/dev/docbook.html#taglib-function says you can have functions, but again, not much information there also.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15964
    
  19

I believe that there's an example of this at IBM DeveloperWorks. I don't recall the URL. They didn't use it the way you're doing, however. They were doing custom validators, I believe. Note also that this isn't a JSF thing, it's a Facelets thing and it applies to static functions, not instance functions (that is, in managed beans). I think the JSF1.2 stuff is actually due to Facelets being merged into JSF proper, but I'd have to RTFM.

EL is a very powerful and very useful facility, but it should be used advisedly (unfortunately a lot of people don't). Adding custom functions to the EL language isn't a trivial task, and the results may not be easily reusable in future-generation apps unless well designed. Not that anything is as reusable as we wish, well-designed or not.

The more compelling reason to go light on the EL is that it risks pushing model/controller/backend logic into the View, which is also why I recommend not mixing in JSTL and JSF. There's a reason for having a Model/View/Controller paradigm. It makes complex UI stuff simpler by designating where in the overall structure you find specific functions so that you don't have to play hide-and-seek for them and you'll know how they interact.

Generally, given a choice between complex EL and a backing bean property, I'll go with the property. In some cases, this means constructing the backing bean or members of the backing bean as decorators for more general-purpose beans such as domain model objects.

In the case of a display property like what you're doing, another option might be a formatter. Since the whole purpose of a backing bean is to provide the MVC model object, actually generating a "property" dynamically for output is not something you'd normally do. Value properties are normally simpler and more efficient when backed by internal instance members. My main use for virtual properties is for display control where I'd use them (for example) to provide a context-sensitive value for the "disabled" and "rendered" attributes.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: JSF 1.2 passing parameter to Managed Bean method
 
Similar Threads
passing parameter from non JSF URL to JSF backing bean
Input row select on data table does not get called
JSF ArralyList rendering to Target page is throwing Class Cast Exception
Managed bean property gets displayed on a page, but then becomes null
Why can't I get object in request scope?