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.
Related
I recently read this article from Neil Griffin Making Distinctions Between Different Kinds of JSF Managed-Beans and it got me thinking about the distinction between different beans in my own application. To quickly summarise the gist:
Model Managed-Bean: This type of managed-bean participates in the
"Model" concern of the MVC design pattern. When you see the word
"model" -- think DATA. A JSF model-bean should be a POJO that follows
the JavaBean design pattern with getters/setters encapsulating
properties.
Backing Managed-Bean: This type of managed-bean participates in the
"View" concern of the MVC design pattern. The purpose of a
backing-bean is to support UI logic, and has a 1::1 relationship with
a JSF view, or a JSF form in a Facelet composition. Although it
typically has JavaBean-style properties with associated
getters/setters, these are properties of the View -- not of the
underlying application data model. JSF backing-beans may also have JSF
actionListener and valueChangeListener methods.
Controller Managed-Bean: This type of managed-bean participates in
the "Controller" concern of the MVC design pattern. The purpose of a
controller bean is to execute some kind of business logic and return a
navigation outcome to the JSF navigation-handler. JSF controller-beans
typically have JSF action methods (and not actionListener methods).
Support Managed-Bean: This type of bean "supports" one or more views
in the "View" concern of the MVC design pattern. The typical use case
is supplying an ArrayList to JSF h:selectOneMenu drop-down
lists that appear in more than one JSF view. If the data in the
dropdown lists is particular to the user, then the bean would be kept
in session scope.
Utility Managed-Bean: This type of bean provides some type of
"utility" function to one or more JSF views. A good example of this
might be a FileUpload bean that can be reused in multiple web
applications.
This made sense to me and for the past few hours I have been refactoring my code and came up with the following with respect to the user login:
The AuthenticationController is an example of a Controller Managed-Bean. It is request-scoped and features two getters and setters for setting a username and password, and two navigation methods, authenticate and logout, navigating the user to either their private area upon successful login, or back to the main page when logging out.
The UserBean is an example of a Support Managed-Bean. It is session-scoped and features an instance of User class (which would be null when you are not authenticated) with a getter and setter, nothing more.
The AuthenticationController has this user as a managed property (#ManagedProperty(value = "#{userController.user} private User user;). Upon successful authentication, the AuthenticationController would set the managed property to the actual user instance with the corresponding username that was used for the login.
Any new beans would be able to grab the user as a managed property as well and pull the data they need, such as group membership for instance, if the User class would feature a list with group names.
Would this way be the proper way to go about with regard to the seperation of concerns?
This is a very subjective question. I personally disagree that article and find that it's giving really bad advice to starters.
Model Managed-Bean: This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties.
I would absolutely not make or call it a managed bean. Just make it a property of a #ManagedBean. For example a DTO or JPA #Entity.
Backing Managed-Bean: This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
This way you keep duplicating and mapping the properties of the entity in the managed bean. This makes no sense to me. As said, just make the entity a property of the managed bean and let the input fields refer it directly like #{authenticator.user.name} instead of #{authenticator.username}.
Controller Managed-Bean: This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
This describes the #RequestScoped/#ViewScoped #ManagedBean class pretty much. Whether event listener methods are allowed or not depends on whether they are specific to the view which is tied to the bean and/or are for their job dependent on the bean's state. If they are, then they belongs in the bean. If not, then they should be a standalone implementation of any FacesListener interface, but definitely not a managed bean.
Support Managed-Bean: This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope.
Fine. For application wide data like dropdown lists just use an #ApplicationScoped bean and for session wide data like logged-in user and its preferences just use a #SessionScoped one.
Utility Managed-Bean: This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.
This makes not really sense to me. Backing beans are usually tied to single views. This sounds too much like an ActionListener implementation which is to be used by <f:actionListener> in command components to your choice. Definitely not a managed bean.
For kickoff examples of the right approach, see also:
Hello World example in Our JSF wiki page
"Bookstore CRUD" example in this answer
"Master-detail" example in this answer
JSF Service Layer
Communication in JSF 2
I want to be able to have a Primefaces tree in 2 places on my page. The reason is that I want to have the two trees with the same data have exacly the same state- the same nodes expanded etc. I tried to bind both instances to the same value in backing bean but this results in only one of them rendering. Am I doing it wrong? Should this be solved differently?
The related question (with slightly different requirements) states that one should not do this, but if not- what should be done?
JSF component disappears after binding
Edit 1
I have noticed that I can share the selection value easily with the 'value=', but the real problem is sharing which nodes are expanded and which are collapsed. I do not know if this is stored on the server, or if it can be stored on the server at all.
I tried to bind both instances to the same value in backing bean but this results in only one of them rendering. Am I doing it wrong?
This is definitely wrong. Each component binding should resolve to an unique request scoped property which is not shared by any other component, nor lives longer than the request scope.
Should this be solved differently?
Bind them to different properties. If you want a dynamically expansible property, use a Map<String, UIComponent>.
private Map<String, UIComponent> components = new HashMap<String, UIComponent>();
// Getter (no setter necessary).
which can be used as
<x:someComponent binding="#{bean.components.foo}" />
<x:someComponent binding="#{bean.components.bar}" />
<x:someComponent binding="#{bean.components.baz}" />
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 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.
I have a update form, with composite keys All composite keys are displayed in outputbox as I have hidden field for each composite keys. These outputbox values are empty after validation error. How do I resolve this. I am on the same page so doesn't it has to have the values.
This is indeed a non-intuitive behaviour of the h:inputHidden (I've ever filed a issue against it at the Mojarra issue list, but they didn't seem to do anything with it). The whole problem is that the component's value unnecessarily is also taken into the entire validation cycle while there's no means of user-controlled input. It will get lost when the validation fails. There are at least three ways to fix this non-intuitive behaviour.
First way is to use the binding on the h:inputHidden instead:
<h:inputHidden binding="#{bean.hidden}" />
This way the value won't undergo the unnecessary validation cycle. This however requires changes in the way you get/set the values in the backing bean code. For example:
private HtmlInputHidden hidden = new HtmlInputHidden(); // +getter +setter.
public void setHiddenValue(Object hiddenValue) {
hidden.setValue(hiddenValue);
}
public Object getHiddenValue() {
return hidden.getValue();
}
Second (and IMHO the preferred way) is to use Tomahawk's t:saveState instead.
<t:saveState value="#{bean.property}" />
The major advantage is that you don't need to change anything in the backing bean code. It will restore the value early before the apply request values phase. You only need to add extra libraries if not done yet, but as Tomahawk provides much more advantages than only the t:saveState, such as the in basic JSF implementation missing components/features t:inputFileUpload, t:dataList, t:dataTable preserveDataModel="true", t:selectOneRadio layout="spread" and so on, it is worth the effort.
The third way is to store it in a session scoped bean, but you actually don't want to do that for request scoped variables. It would only give "wtf?" experiences when the enduser has multiple tabs/windows open in the same session.