Source code available now!

by Matt Pickell for JavaPureFaces, ajax, richfaces

We have now put the source code and a small demonstration application (template application) for Java Pure Faces!

Please give us feedback or let us know if you have any questions!

Get it here!

Ajax in Java Pure Faces using RichFaces

by Matt Pickell for JavaPureFaces, ajax, richfaces

We have been busy transitioning Java Pure Faces to begin using Ajax! This included integrating RichFaces into the framework, and with that there were many details that we needed to work out.  But… Ajax is here!

One major issue we needed to overcome was that with RichFaces does not support dynamically replacing components in the JSF tree, only updating.  Of course it is possible but requires a lot of dynamic component building in the backing bean or it can be simulated with the use of the ‘render’ flag and multiple existing components.  We found a way through actionListeners to solve this issue.   JPF is still required to maintain a ‘placeholder’ on the page where a component will be created, but the contents of that container are totally dynamic.

So far we have a small subset of components transitioned to Ajax and we have set a goal to have an open source version of the framework out this year. There is still work to do on it, and more components to implement, and (always!) some cleanup!

For now, let us know what you think of this first demo! It is small, but begins to show how nice the Ajax usage can be!

PureStock Ajax Demo

A look at Seam and Java Pure Faces

by Matt Pickell for JavaPureFaces

A recent comment on this blog asked if Java PureFaces was different than Seam. Being unfamiliar with Seam, I needed to research it and do some reading. My quick review of Seam only skimmed the surface. What I found is that Seam and Java PureFaces are indeed very different, but that there are also some interesting overlaps. Here is a little of what I found:

  • Scope:
    • JPF: Java PureFaces is a presentation tier API allowing for the simple creation of object oriented, java-based views. It is not for business-tier logic. That is performed elsewhere in the application. Java PureFaces does, however, allow simple integration of the presentation-tier with the business-tier since you are able to access absolutely any object in the system directly in a purefaces component (see The magic behind Java PureFaces). It also allows any business logic class to handle its own purefaces presentation through the implementation of the PureComponent interface.
    • Seam: Seam, on the other hand, is an application framework that does not handle presentation-tier. It leaves that to some other JSF-based technology, such as Java PureFaces.
  • Beans:

    Java PureFaces uses only a single JSP page tied to a single bean. As seen in The magic behind Java PureFaces, absolutely any object property or method in the system can be access directly by view components, and there is no need to continuously update the faces-config.xml file. Seam has a version of this object access simplification called bijection. It allows the developer to add an annotation to any object and then access that object directly from the view (also without defining the bean in the faces-config.xml file). Because Seam does not handle the view, it needs to resolve dependencies each time a component is invoked in order to maintain state.

    The major difference between Seam and Java PureFaces here is that :

    • In JPF, stateful POJO’s contain the code to create the view directly. When the view is needed, the components are pulled from the POJO and placed into the JSP page. Because the components are pulled each time, they always represent the current state of the object. Actions from the new view can then directly affect that object’s state, changing it for the next view update. An example of this is shown in Java PureFaces – Clean & Simple HTML Output. The example in the linked post shows a method from a POJO used to create the view. It is easy to see how the current state of the object is woven directly into the view.
    • In Seam, the JSP view pulls data from the application as it is rendered, and the view has no state, so Seam handles the maintenance of state. Seam bijection creates a method for exposing beans to the view for both the simplification of development and the maintaining of state.
  • Navigation:
    • JPF: Java PureFaces eliminates the need to create and maintain hardcoded XML navigation rules; only a single JSP page is necessary and all navigation is handled in Java (the topic of a future post).
    • Seam: Seam also allows the developer to avoid static XML by letting action listener methods return the JSF view id as the outcome.
  • Presentation tier:
    • JPF: Java PureFaces is a layer on JSF specifically intended to be used for simplifying view creation by moving away from static template files and into Java.
    • Seam: The presentation tier for Seam can be any technology that supports JSF (per the articles I read, I understand it is branching out to other technologies also). Java PureFaces could be used as the presentation layer for a Seam implementation.


While Seam and JPF are two completely different frameworks, intended for two different parts of the application, there are similarities that are worth noting. JPF implementations could benefit from Seam’s additions that solve issues such as using the browser back-button and bookmarking – presentation-related topics that are out of reach for the framework. The Seam framework could become even more streamlined and simplified by using JPF as its presentation layer – eliminating additional static template files and possibly simplifying bijection even more.

This was a very quick look at Seam and how it is related to JPF. It is an interesting mix that hopefully we can take a deeper look at in the future.


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.

Do you have a choice?

by Ariel Raz for JavaPureFaces

Why are java developers using JSP/XML static-template web frameworks to develop their GUI? Is it really the best API for it?
The reason I have heard is that it allows non-programmers to design and build the GUI, and then have the developer plug into it the code. This is a nice theory, but I haven’t seen it happen this way. I have always had to write both the JSP pages and the java code myself. Many times I did get the GUI “look and feel” from a graphical designer in an HTML format, but that was it.
I cannot see how letting a non-programmer write the JSP/XML is a good way to develop web applications because it requires an enormous, inefficient amount of communication between the GUI designer and the java developer, and it creates a maintenance nightmare.
I think java developers are using JSP/XML static templates because there is currently no better java API to create the web GUI. Am I wrong? If there was a good object oriented java API, would developers still be using JSP/XML static-template web frameworks?

Java PureFaces – Clean & Simple HTML Output

by Matt Pickell for JavaPureFaces

What does the HTML from Java PureFaces look like?  In this post I going to show exactly what mark-up is created.  I’ve cut and pasted a couple of examples from the previous Guess-A-Number demo to show some examples. I’ll start by using a single JSP page for the project:

JSF page for the demo

This is all that is needed in the simplest app JSP page. Here is the code of the createGuessComponent from the demo:

createGuessComponent Java Code

which creates this simple view:

Guess Demo Screen Shot

Guess Demo Screen Shot

and this HTML:

Table Based HTML Java PureFaces output

Or, with the simple swapping of the PurePanelGroup into the code where a PurePanelGrid is currently used, you can get the more updated, non-table based layout (much more CSS-friendly) in the body of the page:

Cleaner HTML output

There is still a table in there. That is configured to allow for an error message next to the input box through JSF messaging. Want to get rid that all tables? That, too, can be easily changed by chaining another option off of the PureInput Component, leaving even smaller, cleaner HTML:

Cleanest HTML output

Although now there is no message for the required input field if the user leaves it blank. This example is shows that when comparing this to the java code that created it, you can now see it is almost line for line (there is no error message, so it is not rendered).

You can use table-based layouts, or work with more current semantic layouts. Either way, it is very easy to create a view.

It is also very easy to manipulate the attributes of the HTML elements, like the style classes in the HTML shown here (class=””). The framework model can support any element attribute, such as DOM “Level 0” Events (onclick, onkeypress, etc.) and inline styles (style=””), to name a few of the more used attributes, by just chaining them onto the component you are adding.

Demo Java PureFaces

by Matt Pickell for JavaPureFaces

Demo it for yourself!

Let’s take a quick walk through Java PureFaces by implementing the JSF guessing number game.
Built in the  Java PureFaces framework, it takes only two classes:

  • GuessNumber — will know how to create a random number to guess and will check it the user number matches the guessing number.
  • GuessNumberView — is responsible to create the GUI and response to the button clicks.

Notice that the code to create the simple GUI, as well as the code that handles the button clicks, is cleanly packaged together.  Very simple!  Compare this to the JSF Version.

Download the demo now! (RAR), (ZIP), (TGZ)

Also, check out the demo applications on the Solutions page.  Both of these major applications were created using  Java PureFaces!

Introducing Java PureFaces!

by Matt Pickell for JavaPureFaces

Introduction to Java PureFaces!

Developing the Web Tier is a big part of designing and developing a web application. Many frameworks exist that attempt to improve this part of the development. These frameworks simplify the process, providing ready tools and improving code reuse.

Most frameworks are developed around a web designer/java developer job split, providing a simple API to the web designers, and an XML/HTML file and a java API for the developers. Examples are Struts and JSF.

Other frameworks are aimed only at java developers and provide a Swing-like API, allowing the developers to develop a web application with only the java language. The developer code can be very object oriented and does not need to be concerned about interacting with HTTP/ JSP/Tags etc. An example of this type of framework is GWT.

Building off of both of these, B6 Systems has created a new framework for Java developers! We call it Java PureFaces. Java PureFaces is built on the very popular JSF framework, but allows the web tier to be designed completely in Java — no massive library of JSP/JSF pages or configuration files necessary.

New framework

Java PureFaces provides a pure Java framework for building the web tier. Java developers can use good object oriented solutions, increase code reuse, speed up development, and simplify code maintenance without worrying about many of the web/http concepts like HTTP, JSP, XML, Tags, HTTP sessions, etc. The API is very simple and easy to learn and use.

Like JSF, Java PureFaces binds object attributes into the GUI, and binds commands and link buttons to object methods. Also, JSF components are used to render the HTML. Unlike JSF, Pure Java Faces attributes and commands can be bound to any POJO object, not only to a backing bean. An advantage of this method is that the bindings themselves can be tested with JUnit.

Because the framework uses JSF, it is very extensible. In order to create a new component, just extend the UIComponent JSF class. Also, only a single HTML page and backing bean are necessary as the container for the web application (this simplicity does mean that, like some other frameworks, you cannot refresh the page or use the browser back button).

Check back, I’m going to be adding more information soon!