Object-oriented API

by Matt Pickell for JavaPureFaces

Object-Oriented API

For the next topic on Java PureFaces, I want to talk about how Java PureFaces promotes object-oriented programming.

The PureComponent Interface

All Java PureFaces components implement a single interface, PureComponent, that enable them to be used in the framework. This means that, unlike some other frameworks, you do not have to extend a framework-specific object in order to have the functionality of the framwork. In a language that does not allow double-inheritence, being forced to extend another object creates inflexibility. Instead, it allows any object in the application to contain its own display code. It also allows for the creation of custom components that can be easily used throughout the system.

Component Objects

Component creation is very easy with Java PureFaces. All containers, such as PurePanelGrid and PurePanelGroup, take objects that implement PureComponent, and all components are PureComponents. To create a new custom component, you simply implement the interface and then build whatever component you need.

In this example, a simple component – that approximates an HTML label element – is created. By implementing the PureComponent interface, the object is required to implement the createUIComponent method. Inside this method, the component is created from other building blocks. The rest of the object can contain any getters and setters necessary, along with any helper methods, or really just anything at all.

This particular example makes use of another Java PureFaces convenience object called PureEditableValue. This component is a very simple object that holds a reference to a property, and contains the necessary getter and setter needed to access that property. Through the use of generics, that property can be of any type.

public class LabelAndInputComponent<E> implements PureComponent {

private String label;
	private PureEditableValue<E> editableValue;
	public LabelAndInputComponent(String label, E value) {
		this.label = label;
		this.editableValue = new PureEditableValue<E>(value);
	public PureComponent createUIComponent() {
		PurePanelGrid panelGroup = new PurePanelGrid(2);
		panelGroup.add(new PureOutput(label).setStyleClass("lableStyleClass"));
		panelGroup.add(new PureInput(editableValue).setStyleClass("inputStyleClass"));
		return panelGroup;
	public E getValue(){
		return editableValue.getValue();

This component can now be used anywhere, as shown in the example below. The component is a completely object-oriented solution that can be tested through JUnit. It can extend anything it wants, and of course can implement as many interfaces as necessary. There is absolutely no restriction on making any object a Java PureFaces component.

//.. Some other view object
		private LabelAndInputComponent<String> label = new LabelAndInputComponent<String>("A Label", "default text"); // example

		public PureComponent createUIComponent() {
			// Create a DIV element that contains a label component
			PurePanelGroup panelGroup = new PurePanelGroup();
			return panelGroup;

Easier Maintenance

The final topic to cover is the ease of maintenance for a Java PureFaces implementation. For this, I will use the LabelAndInputComponent implementation that we just discussed.

Testing Java PureFaces is very easy, and very powerful. Of course, it is already easy to test the non-Java PureFaces parts of the object in JUnit the same way we would any other time. The additional advantage here is that we can test the bindings of the Java PureFaces components as well.

The way it works is that the framework tests every binding (using the Reflection API) prior to adding it to the ActionListener or ValueChangeListener. This functionality is done immediately when building the component, and an exception is thrown if something does not check out correctly. Testing the bindings is as simple as:

		public void testLabelAndInputComponentImplementation() {
			ThatTestObject obj = new ThatTestObject();

This simple test creates the component and tests that all bindings are valid and able to be resolved.

And finally there is general maintenance. Everything is inside Java. The views are maintained by editing existing objects and components with the ease of whatever development environment you use. There are no JSP files to maintain, there is no XML to update. Productivity is increased by be able to work on all of the code without having to switch gears and use a separate environment. Changes are immediately available when you rebuild the project.

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.