aspose file tools*
The moose likes JSF and the fly likes Can we use static method in a Managed Bean to fetch request parameter values Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Can we use static method in a Managed Bean to fetch request parameter values" Watch "Can we use static method in a Managed Bean to fetch request parameter values" New topic
Author

Can we use static method in a Managed Bean to fetch request parameter values

Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
I have come accross following code in a managed bean:


Please suggest if it is fine to use static method for the purpose of fetching request parameter values. My doubt is: A new managed bean object is created for every logged in user, so if we pull param values in a static method, is it possible that parameter values for different users may get intermeixed and correct one may not be fetched at runtime.
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
I think the code would run fine. As the FacesContext.getCurrentInstance() is itself tied to the user session and is a hook for current request.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15646
    
  15

My experience with static methods in general is that far too often I eventually reach a point where I need a non-static implementation of the method instead. I've learned to think twice (or more!) before making anything static. That's not just for JSF, it's for anything. In this particular case, I'd do it static myself, but I've learned to be wary of doing things static without careful consideration.

I don't recommend pulling request parameters by brute force in JSF. Ignoring for the moment that JSF is designed for Inversion of Control (IoC), where you don't "pull" things, you get them pushed for you, there is a more serious problem in that JSF operates using postbacks, which are done via HTTP POST operations. URL GET parameters will therefore often not be there when you need them, and JSF already handles POST values.

Most of the few reasons there were for for pulling parameters directly have been addressed by JSF2, which can use its IoC mechanism to directly inject the parameter values as backing bean properties for you automatically.


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

Joined: Aug 19, 2010
Posts: 43
Thanks for the input.
The application I am working on is on JSF1.1. So the alternative to pulling parameter seems to use inputHidden fields in the JSP.
Are there any security concerns with using inputHidden field on JSP?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15646
    
  15

There are security issues ANY time you send data out to the client. What you get back may be hacked.

JSF's design intends to pass data between backing beans on the server without sending anything to the client that isn't expected to be modified by the client.
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
Let us consider followig scenario.
There is a datatable on JSP view. The list binded to the datatable contains 10 VO's (POJOs). Each VO has a property:ID.
Suppose there is a commandlink in a column in every row of datatable, on click of which a backing bean method is to be invoked.
How can we identify the datatable row (VO) whose commandlink was clicked to invoke the backin bean method. I know of following ways:
1. Using f:param with each commandlink to pass the ID.
2. Using hidden inputField on the JSP to pass on the ID of element clicked.
3. Using CheckBoxes on JSP in each row of datatable to identify which row the commanlink belonged to.

Please advise how we can achieve this without using above ways, specially when the use of checkbox is prohibited.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15646
    
  15

Checkboxes and radio buttons are not good choices for Submit controls, regardless of the platform. They were intended to allow select options, not to initiate actions. So ruling them out here doesn't lose anything.

The preferred method of submitting a request based on a row of a dataTable would be a commandLink or commandButton. In either case, the control would then be associated with a backing bean action method.

How does the action method know what row of the table was selected? By employing a facilitator.

JSF2 did everyone a disservice in that it allows people to "brute-force" associate an ordered collection of objects directly (or so it appears) with the corresponding dataTable VDL element. In actuality, a facilitator model is requred to manage the cursor(s) used to render the table and to handle the identification of a row selected. This facilitator model is an instance of class DataModel, which contains the extra functionality to decorate a generic collection with JSF-specific support functions. The 2 most common DataModel classes are ListDataModel and ArrayDataModel. I didn't think this object was optional in JSF1, but it sounds like maybe it was.

The DataModel wraps the raw collection, either via its setWrappedData() method or as a function of the constructor. Either way is an acceptable choice. When you do that, your action method can then invoke the getRowData() or getRowIndex() to obtain either the actual row raw model object for the the row clicked on or its index in the raw collection. So as long as you use this intermediary model, you won't have to play around with either raw HTML access methods or esoteric JSF internal functions. Nor will you have to put support data on the View Definition itself. JSF takes care of it all simply and cleanly.

As a side notice, as far as I am aware, there is always going to be a DataModel object, but if you associate the dataTable with a raw collection instead of a DataModel wrapping that collection, an anonymous DataModel will be constructed for you. Since it's anonymous, there's no simple clean way to get access to it in order to invoke its getRowData() method. You're not saving anything by doing that unless you are implementing a display-only table (without row-selection), and even then, it's only a small amount of coding time saved, since the actual work of constructing the fa├žade DataModel is done either way.

Note that because the DataModel holds context for data coming and going from the displayed table, it must not be in Request scope.
Abhishk Singh
Ranch Hand

Joined: Aug 19, 2010
Posts: 43
Using datamodel seems to be cleaner and more appropriate option.
Thank you for the explanation.
 
wood burning stoves
 
subject: Can we use static method in a Managed Bean to fetch request parameter values
 
Similar Threads
problem with sequence of events during JSF lifecycle
querystring values and GET method
cannot set managed-property parameter with h:selectOneMenu value
Passing Params
How to access static variable directly from jsf page