As a contribution to Simon Brown's series of articles where he compares Java web application frameworks, I created a RIFE version of the read-only blog that currently serves as an example.

What is RIFE?

RIFE is a full-stack component framework to quickly and consistently develop and maintain Java web applications.

I'd like to underline that we focus on maintainability and development comfort. We firmly believe that it's important to have a high-level, self-documenting overview of your web application. This allows teams to work independently and simultaneously on different parts. At any moment they can integrate their work without stepping on each other's toes. This approach led to the creation of a site-structure that handles both the logic flow and the data flow, as a state machine. Any modification in there will correctly propagate throughout the entire framework, reducing repetition and redundancy to a minimum. I will explain more about the site-structure later in this article.

Let's dive into the example. Basically, we have an application with three pages. The Home page displays a list of blog entries, which can optionally have an excerpt. When an excerpt is present, a link will be available towards to full entry Detail page. Also, in case a user tries to access an invalid blog entry, a nice Not Found page will be displayed.

Abstract base element

Each page in RIFE is implemented through an element. Each of them requires access to a blog service and will print out a template that contains the name and the description of the blog. I created the following abstract base class that will be extended in the concrete elements:

The setters will be used to inject the objects through inversion of control.

The initialize() method functions like a default constructor, except that it is called when the entire web context is set up, and getBlog() is simply a convenience method for the extending classes.

Reusable template blueprint

Apart from the page-specific content, the layout of each template will be exactly the same. I thus created a common blueprint that will later be included into the other templates.

The highlighted tags are values (v tag) that function as placeholders and have unique names. When the tag has both a beginning (${v name}) and an ending (${/v}), the enclosed content will be used as the default when nothing has been assigned to it. The 'WEBAPP:ROOTURL' value will be automatically replaced by RIFE with the root URL of your web application. This makes it easily relocatable under another name, included into another application or onto another web server.

Note that RIFE supports many alternative template tag syntaxes, this one is inspired by Velocity, others are for example valid HTML and allow you to preview the file in a regular browser.

Home element

This is the implementation of the home element. It simply iterates over the blog entries and displays them in the template. If the excerpt contains data, it will create a "more" link that carries over the entry ID towards another element. The template is printed at the end.

Since the display of each entry will be the same for this element and the next Detail element, I first extracted that into a reusable template snippet. This snippet will later be included in other templates through the include tag (i tag).

The template of the home element will now include the blueprint that we created earlier and this snippet. It also introduces a new concept, template blocks (b tag). These will be stripped out and are available to construct your layout with. You'll also see a special block, the block value (bv tag) which will automatically assign its content to the value with the same name. In this case, the "page content" value will be filled into the blueprint.

${i blog.blueprint/}   ${bv page content}     ${v entries}${/v}   ${b entry}     ${i blog.entry/}           ${b excerpt}       ${v excerpt/}       <p><a href="${v EXIT:QUERY:more/}">Read more</a></p>     ${/b}             ${b body}${v body/}${/b}   ${/b}   ${/bv}

Note that there's a special value tag with the prefix "EXIT:QUERY:". The content of these tags is generated by RIFE to target the correct elements and at the same time carry over the relevant view state.

Detail element

The detail element receives the ID of the entry that it has to display, it will be injected through the corresponding setter method. When it can't find an existing entry, it simply exits to display the "not found" page:

The template of this element contains nothing new and reuses the blueprint and the entry templates again. However, instead of conditionally setting blocks to fill in the "entry content" value in the blueprint, it does so directly with a block value tag.

${i blog.blueprint/}   ${bv page content}     ${i blog.entry/}   ${bv entry content}${v body/}${/bv}     ${/bv}

NotFound element

The NotFound element indicates that an entry wasn't found by setting the correct HTTP status code and printing out the template:

The template is trivial:

${i blog.blueprint/}   ${bv page content}     <h3>Page not found</h3>   ${/bv}

Meta data through constraints

Simon's domain model was left untouched. However, the application requirements specify richer information about the data model: the date has to be formatted according to the blog's timezone and locale, and the excerpt and body properties contain HTML instead of text. Since RIFE automatically encodes text that is filled into the templates, you need to indicate that it has to display these text fragments raw. Instead of handling this everytime individually throughout your application, it's better to centralize this as meta data that augments the BlogEntry bean. RIFE will detect this meta data when it interfaces with BlogEntry instances, causing RIFE's functionalities to adapt accordingly.

This is the meta data class that will be automatically picked up by RIFE and merged into the BlogEntry class:

domain/BlogEntryMetaData.java

Site structure

RIFE's site-structure is the basis of most of the neat features in the web engine, most of which are not applicable to Simon's simple blog example. The declaration of the site-structure can be done in a variety of ways. At the core we have pure Java builders with fluent interfaces (chainable setters) which can be accessed directly, but we additionally have a collection of wrapper declaration languages like Groovy, Janino and XML. The declaration can also be fully automated through the registration of custom handlers, which is for example used by RIFE/Crud to automatically generate entire CRUD interfaces from your domain model. You can freely choose which declaration method you prefer and mix them together. Everybody is thus able to use what feels the most appropriate and the most comfortable.

In this example, I opted for the XML declaration method, since it's the most widely used by our users. The reason for this is that it allows you to easily intervene in existing application flows without having to recompile or require access to the sources. You can also easily combine several projects and link their logic flow and data flow together, or change the site-structure on a production server without having to redeploy the entire application. However, please remember, if you have any aversion to XML, you're free to use the plain Java method instead, if that's what you prefer.

The site structure of this example is as follows:

You can clearly see that each element has an ID and an implementation. They also declare a "template" property that will make RIFE inject the appropriate template instance when the elements are processed.

The Home element is the arrival of the site, which can be seen as the default element (something like index.html in static sites). It also has one flow link towards the Detail element that contains a data link to carry over the entry ID.

The Detail element will handle pathinfo data. Through a mapping declaration, the entry ID will be extracted from URLs like this: "/detail/3". Additionally, every link that RIFE generates towards the Detail element will use this pathinfo mapping to avoid the presence of query parameters.

The NotFound element hasn't got an URL, since it's only accessed when the "not found" exit is triggered.

Servlet containers and the repository

RIFE takes care of the entire life-cycle of your application through what we call the Repository. By adding the RIFE filter to web.xml, your application co-exists freely in the same URL space as any other web application. This is the only change that you will ever have to do there, and by using the RIFE base archive or the Jumpstart as a starting point, you'll never even have to touch this file. The rep.path init parameter points towards the XML declaration of the repository which is looked up through the classpath. Alternatively, you can use the lifecycle.classname init parameter and point it towards your custom life-cycle class that sets up its own repository in pure Java without XML.

This is the relevant part of the web.xml file:

The repository contains a number of participants and application-wide properties. Participants will be started up and shut down together with your application, and they serve as object factories or services. RIFE will handle inter-participant dependencies transparently and figures out the appropriate execution order.

This is the repository declaration of our example:

BlogServiceProvider is a custom participant that gives access to a BlogService instance that will be used as an injected property throughout the entire application. This participant interacts directly with the domain model that Simon wrote and looks like this:

The second participant initializes the site structure by using the blog.xml declaration that I explained before.

Conclusion

RIFE clearly isolates all important parts and provides a component-based web application development model with very intuitive code inside your view layer. The site structure provides a high-level overview of your application and takes care of all state management and URL handling. You get access to powerful features like native Java continuations, state handling without sessions, URL localization, conversational state, three-dimensional flows, content management integration, transparent meta data merging and much more. The simple things however still remain very easy to do.

You can download a ready-to-run archive of this example to play with, or browse the Subversion repository.