How does the ‘binding’ attribute work in JSF? When and how should it be used?

by

How does it work?

When a JSF view (Facelets/JSP file) get built/restored, a JSF component tree will be produced. At that moment, the view build time, all binding attributes are evaluated (along with id attribtues and taghandlers like JSTL). When the JSF component needs to be created before being added to the component tree, JSF will check if the binding attribute returns a precreated component (i.e. non-null) and if so, then use it. If it’s not precreated, then JSF will autocreate the component “the usual way” and invoke the setter behind binding attribute with the autocreated component instance as argument.

In effects, it binds a reference of the component instance in the component tree to a scoped variable. This information is in no way visible in the generated HTML representation of the component itself. This information is in no means relevant to the generated HTML output anyway. When the form is submitted and the view is restored, the JSF component tree is just rebuilt from scratch and all binding attributes will just be re-evaluated like described in above paragraph. After the component tree is recreated, JSF will restore the JSF view state into the component tree.

Component instances are request scoped!

Important to know and understand is that the concrete component instances are effectively request scoped. They’re newly created on every request and their properties are filled with values from JSF view state during restore view phase. So, if you bind the component to a property of a backing bean, then the backing bean should absolutely not be in a broader scope than the request scope. See also JSF 2.0 specitication chapter 3.1.5:

3.1.5 Component Bindings

…

Component bindings are often used in conjunction with JavaBeans that are dynamically instantiated via the Managed
Bean Creation facility (see Section 5.8.1 “VariableResolver and the Default VariableResolver”). It is strongly
recommend that application developers place managed beans that are pointed at by component binding expressions in
“request” scope. This is because placing it in session or application scope would require thread-safety, since
UIComponent instances depends on running inside of a single thread. There are also potentially negative impacts on
memory management when placing a component binding in “session” scope.

Otherwise, component instances are shared among multiple requests, possibly resulting in “duplicate component ID” errors and “weird” behaviors because validators, converters and listeners declared in the view are re-attached to the existing component instance from previous request(s). The symptoms are clear: they are executed multiple times, one time more with each request within the same scope as the component is been bound to.

And, under heavy load (i.e. when multiple different HTTP requests (threads) access and manipulate the very same component instance at the same time), you may face sooner or later an application crash with e.g. Stuck thread at UIComponent.popComponentFromEL, or Threads stuck at 100% CPU utilization in HashMap during JSF saveState(), or even some “strange” IndexOutOfBoundsException or ConcurrentModificationException coming straight from JSF implementation source code while JSF is busy saving or restoring the view state (i.e. the stack trace indicates saveState() or restoreState() methods and like).

Also, as a single component basically references the rest of the entire component tree via getParent() and getChildren(), when binding a single component to a view or session scoped bean, you’re essentially saving the entire JSF component tree in the HTTP session for nothing. This will get really costly in terms of available server memory when you have relatively a lot of components in the view.

Using binding on a bean property is bad practice

Regardless, using binding this way, binding a whole component instance to a bean property, even on a request scoped bean, is in JSF 2.x a rather rare use case and generally not the best practice. It indicates a design smell. You normally declare components in the view side and bind their runtime attributes like value, and perhaps others like styleClass, disabled, rendered, etc, to normal bean properties. Then, you just manipulate exactly that bean property you want instead of grabbing the whole component and calling the setter method associated with the attribute.

In cases when a component needs to be “dynamically built” based on a static model, better is to use view build time tags like JSTL, if necessary in a tag file, instead of createComponent(), new SomeComponent(), getChildren().add() and what not. See also How to refactor snippet of old JSP to some JSF equivalent?

Or, if a component needs to be “dynamically rendered” based on a dynamic model, then just use an iterator component (<ui:repeat>, <h:dataTable>, etc). See also How to dynamically add JSF components.

Composite components is a completely different story. It’s completely legit to bind components inside a <cc:implementation> to the backing component (i.e. the component identified by <cc:interface componentType>. See also a.o. Split java.util.Date over two h:inputText fields representing hour and minute with f:convertDateTime and How to implement a dynamic list with a JSF 2.0 Composite Component?

Only use binding in local scope

However, sometimes you’d like to know about the state of a different component from inside a particular component, more than often in use cases related to action/value dependent validation. For that, the binding attribute can be used, but not in combination with a bean property. You can just specify an in the local EL scope unique variable name in the binding attribute like so binding="#{foo}" and the component is during render response elsewhere in the same view directly as UIComponent reference available by #{foo}. Here are several related questions where such a solution is been used in the answer:

See also:

More Related Contents:

  1. Binding attribute causes duplicate component ID found in the view
  2. What is component binding in JSF? When it is preferred to be used? [duplicate]
  3. commandButton/commandLink/ajax action/listener method not invoked or input value not set/updated
  4. How to include another XHTML in XHTML using JSF 2.0 Facelets?
  5. How to reference CSS / JS / image resource in Facelets template?
  6. How can I pass selected row to commandLink inside dataTable or ui:repeat?
  7. How to provide a file download from a JSF backing bean?
  8. When should I use h:outputLink instead of h:commandLink?
  9. h:commandButton/h:commandLink does not work on first click, works only on second click
  10. Spawning threads in a JSF managed bean for scheduled tasks using a timer
  11. When to use f:viewAction / preRenderView versus PostConstruct?
  12. Retaining GET request query string parameters on JSF form submit
  13. Obtaining Facelets templates/files from an external filesystem or database
  14. How to call JSF backing bean method only when onclick/oncomplete/on… event occurs and not on page load
  15. What’s the view build time?
  16. Bean Validation @NotNull, @NotBlank and @NotEmpty does not work in JSF+Tomcat
  17. Difference between Mojarra and MyFaces
  18. What is the use of faces-config.xml in JSF 2?
  19. Avoiding duplicate ids when reusing facelets compositions in the same naming container
  20. How to implement a dynamic list with a JSF 2.0 Composite Component?
  21. PrimeFaces validator not fired
  22. How to handle session expiration and ViewExpiredException in JSF 2?
  23. How does JSF 2 ConversationScope work?
  24. Creating FacesMessage in action method outside JSF conversion/validation mechanism?
  25. JSF does not populate @Named @RequestScoped bean with submitted input values
  26. Initialization of List in a JSF Managed bean
  27. PrimeFaces commandButton doesn’t navigate or update
  28. java.lang.IllegalStateException at com.sun.faces.context.FacesContextImpl.assertNotReleased
  29. How to escape f:selectItem itemLabel attribute
  30. JSF 2 dataTable row index without dataModel

Leave a Comment