How to use static method in a Managed Bean to fetch request parameter values
How to use static method in a Managed Bean to fetch request parameter values
I have come accross following code in a managed bean:
public static String getFacesParamValue() {
return (String) FacesContext.getCurrentInstance().getExternalContext()
.getRequestParameterMap().get("paramFromJSP");
}
public static String getFacesParamValue() {
return (String) FacesContext.getCurrentInstance().getExternalContext()
.getRequestParameterMap().get("paramFromJSP");
}
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.
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.
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.
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.
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