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.

Leave a Reply