HI,
There are many ways to get the bean instances from the JSF context. In the following two way:
Bean bean = (Bean) request.getAttribute("beanName");
and
FacesUtils.getManagedBean("beanName");
What is the difference in above two ways. In which case we have to use either ways. Please clarify me.
Use the first if you're not inside the JSF context (aka the FacesContext), e.g. inside a servlet. The second way is unclear since FacesUtils is not part of standard JSF implementation (it's likely a homegrown or 3rd party library). But if it grabs it by the FacesContext, then it works only when you're already inside the JSF context (i.e. inside a JSF managed bean).
Related
As described in this question I try to perform some field validation in a form on the backing bean side. For this I would like to access the violating fields to mark them.
From searching the web there seem to be two ways to do this:
store the components in the backing bean for access and use them in the JSF pages via the binding attribute.
Use standard value binding in the JSF pages and when needing access to a component from the bean, look it up via UIViewRoot.findComponent(String id)
As far as I can see both ways have drawbacks:
Component bindings blows up the backing bean with variables and getters/setters, some sites strongly discourage the use of component binding at all. In any case, a request scope is advised. On the other hand, findComponent() always traverses the tree, which may or may not be costly, right? (Plus, at the moment I can't find my component at all, but that is another problem)
Which would be the way to go? Are these interchangeable alternatives and if not, based on what criteria do you chose? Currently I just don't have enough insight to make a decent decision...
First of all, regardless of the choice, both are a poor practice. See also How does the 'binding' attribute work in JSF? When and how should it be used?
If you had to make the choice, component bindings are definitely faster and cheaper. It makes logically completely sense that a tree scan as done by UIComponent#findComponent() has its performance implications.
Indeed, the backing bean holding the component bindings must be request scoped, but you could easily inject a different scoped backing bean holding the business logic in it by #ManagedProperty.
A cleaner approach would be to use a Map as holder of all component bindings. You only need to add the following entry to faces-config.xml:
<managed-bean>
<managed-bean-name>components</managed-bean-name>
<managed-bean-class>java.util.HashMap</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
This can just be used as
<h:inputSome binding="#{components.input1}" />
<h:inputSome binding="#{components.input2}" />
<h:inputSome binding="#{components.input3}" />
And this can be obtained in other beans as
Map<String, UIComponent> components = (Map<String, UIComponent>) externalContext.getRequestMap().get("components");
This way you don't need to worry about specifying individual properties/getters/setters. In the above example, the Map will contain three entries with keys input1, input2 and input3, each with the respective UIComponent instance as value.
Unrelated to the concrete question, there may be a much simpler solution to the concrete problem as you described in the other question than performing the validation in the action method (which is actually Bad Design). I've posted an answer over there.
This question already has answers here:
How does the 'binding' attribute work in JSF? When and how should it be used?
(2 answers)
Closed 7 years ago.
I have read about component binding with binding attribute in following questions:
JSF component binding - some confusion
component binding vs findComponent() - when to use which?
I understand that it binds the UI component behind the JSF tag in the view to an UIComponent property in the backing bean. However, I am confused what the use of component binding is and when we should use it. Can someone explain it in a more simpler way and give some practical examples?
You should use it if you want to have access to the entire UIComponent instead of just only its value. For example, to access some methods which can't be invoked/bound in the view. This is answered in the 1st question you found: JSF component binding - some confusion
The 2nd question which you found, component binding vs findComponent() - when to use which?, merely answers "binding versus findComponent()", it does not answer "binding versus value" at all as you seem to think. Please don't get confused by this. value would obviously win over binding.
In real world code, component binding to the backing bean is often only used whenever the developer needs to manipulate its children programmatically by e.g. component.getChildren().add(...). The bean should however be request scoped. A broader scope may lead to inconsitenties as component instances are basically created on a per-request basis and shouldn't be shared across multiple requests. The view scope can also, but this is very memory inefficient, and on Mojarra versions older than 2.1.18, partial state saving must also be turned off, otherwise the view scoped bean instance referenced by binding will implicitly be recreated on every request. See also JSTL in JSF2 Facelets... makes sense? for a related answer.
It's also possible to bind the component to "the view". E.g.
<h:someComponent binding="#{some}">
This refers to an instance of UIComponent in the Facelet scope ("page scope"). This enables you to use for example #{some.clientId}, #{some.value} elsewhere in the same page. Note that no backing bean is involved here. See also JSF component binding without bean property.
Here are some real world use appliances of binding attribute:
disabling second text field after data validation through ajax of first text field
Check which form has an error
Input text validation based on drop-down list selection
How to let validation depend on the pressed button?
How to implement row numbering into h:dataTable
Split java.util.Date over two h:inputText fields representing hour and minute with f:convertDateTime
read this answer:
What is the advantages of using binding attribute in JSF?
However, a lot of people in the community do not recommend binding. See this article for example:
http://drewdev.blogspot.com/2009/01/jsf-component-binding-stinks.html
I have the following button:
<h:commandButton
disabled="#{mybean.searching}"
binding="#{mybean.searchButton}"
actionListener="#{mybean.searchForLicenses}"
value="Search" />
When I debug I see that the actionListener is called twice first, then three times, next click four times and so on.
It seems like on every reload the actionListener is registered one more time.
I'm using Mojarra 2.1.3 (also tried 2.0.6) and Tomcat 7 with IceFaces.
The binding is done that way:
private javax.faces.component.UICommand searchButton;
public void setSearchButton(UICommand searchButton) {
this.searchButton = searchButton;
}
public UICommand getSearchButton() {
return searchButton;
}
That can happen if you've bound the component to a session or application scoped bean instead of a request scoped bean. This is simply a bad design. The very same component would be reused among multiple requests/views. You need to put the bean in the request scope, or to get rid of the component binding altogether.
Note that binding the component directly to a bean is often a sign of poor design somewhere in the code. What is it, the functional requirement and/or problem for which you thought that this is the solution? If you elaborate on that, we may be able to propose the right approach.
Also note that using an action listener alone is also a design smell. I'd expect "searchForLicenses" to be a normal action method. See also Differences between action and actionListener.
The similar issue takes place when component is using binding and validator or valueChangListener and backing bean is of View, Session or Application scope. Then corresponding listeners are called many times but not once during request (+1 time with every new request).
One possible solution is to override jsf class AttachedObjectListHolder which is used for storing component listeners. Current implementation simply add new listener to component even though the same listener is already there. So the proposed fix is to check that listener does not exist before adding it.
Details of the fix you can see here
I can't find any guidance on this question. I am writing a composite component that needs its own backing bean because it interacts with a data base.
The new component also needs to be able to set a value in some other backing bean as the result of some user action.
To do this, the question is do I have to write a #FacesComponent java class or a regular #Model/#Named (I use CDI annotations) type of bean? If you can use either, what is the advantage of one or the other?
Secondary question: will I be able to use CDI #Inject into a #FacesComponent to get my DAOs and such?
Update: I discovered that I can access cc.attr objects with the following code in a regular backing bean:
FacesContext fc = FacesContext.getCurrentInstance();
Object obj = fc.getApplication().evaluateExpressionGet(fc,
"#{cc.attrs.model.location}", Location.class);
So this allows me to obtain attributes. I haven't found out how I can write them yet.
So it seems that the only real reason to do a #FacesComponent is if you want to write rendering code that will output something the normal Facelets tags won't render. Is this correct?
I think BalusC responded to this basic question in this thread.
The main advantage is the ability of a #FacesComponent to access attributes that a UIComponent normally has access to, rather than trying to tie in with EL expressions executed in the bean.
Im currently using JSF2, and i notice the JSF bean could have a lot of responsibility, and if combined will look like lots of codes. These include :
holding the state / data
could be a backing bean for the UI component
action methods definition
action listener methods definition
navigation
calling the services
all the setter n getters
Does it make anysense to break these into several classes or do you usually combine all of them together ?
Currenly for every JSF Bean, i define another class to hold the view data / state along with the setter getters.
How do you usually do it ? Please share your experience !
Thank you =)
Every property which is been used in action(listener) methods needs to stay in the backing bean. The remnant most likely belongs in its own class which can in turn be a different (managed/entity)bean, eventually as a (managed)property of the bean where it originated.