The magic behind Java Pure Faces

by Matt Pickell for JavaPureFaces

In this and the next post, I’m going to talk about the object oriented advantages of Java Pure Faces. Here I’ll describe how we detached the need for a backing bean so that any object or method can be bound to the page.

A quick review: Typically, JSP pages are coupled with a backing bean, which contains any java code used in the page. The backing bean must be defined in the faces-config.xml file, and is the page’s interface to the rest of the system.

My point here is that:

  • It is tedious to define and maintain the mapping of beans in the faces-config file,
  • The JSP page is restricted to accessing methods only in the backing bean.

The designer is forced to maintain a JSP file, an XML, and a java class – for each page in the system (not to mention the navigation mappings, etc).

Java Pure Faces removes this complexity and inflexibility. A backing bean is required, but only one that is used to tie the whole system to a single JSP page… and this bean is never really used after this. At least, not for binding to the page. The objects bound to the page are part of the application.

The magic behind Java Pure Faces is simple, yet extremely powerful. There is rarely, if ever, a need to touch the faces-config file or the JSP page, yet you can bind to any method or field in the system. Here is how it works.

There are two main things that make Java Pure Faces work. The key to it is that in JSF, listeners are called before the binding.

  • Command Buttons / links: When you create a command component through the API, Java Pure Faces binds that component to the single backing bean using a dummy method that simply returns “success.” The work for these components is performed using ActionListeners. First the binding is tested (for testing in JUnit), and then an ActionListener is created from the parameters entered through the API.
  • Inputs: All input types are set up with a default Value Change Listener directed at the desired field entered through the API. Once again, the bindings are tested first using reflection and will throw exceptions for JUnit testing.

That’s all there is to it. (Not how it was meant to be used, but isn’t that where some of the best uses come from?)

This work is all done behind the scenes, and completely removes the restrictions of the standard JSP/XML/backing bean combination. Absolutely any property can be manipulated, and any method can be triggered. This design enables the system to be completely object-oriented, which is the topic for next time.

Finally, here is an example to further clarify how useful Java Pure Faces can be. Using JSF, all backing beans registered in the faces-config file are instantiated at runtime by JSF. What if you want to bind to a persistent entity from Hibernate? Hibernate creates those for you. You cannot do it; an entity cannot be a backing bean. There need to be extra steps to move data from the page to the entity. In Java Pure Faces, this is not an issue. Hibernate instantiates the entity and anything in that entity can be tied directly into a view.

What do you think? This is a work in progress and we’re interested in getting expert opinions.

Leave a Reply