I've been busy building web application content.

• A simple form with three fields
• Under the form, a table shows the previously added records
• The data in the table can grow to several hundred
• Blah blah blah

We've done this many times. And we've got enough tools from here to the mooon and back to get it all done pretty well.

But of late, I've been bitten by the CMS template bug. The sheer power of CMS templates and the vantage point they offer to being able to examine the entire technology landscape AND interact with it is not a thing to be ignored.

A CMS structure

Here is where I define all the fields I can use to configure my application. Example fields include:

• Caption
• Header text
• Footer text
• Preferred style for buttons
• Default page size for table records
• Payment gateway request URL
• Payment gateway success URL
• Payment gateway failure URL
• etcetera

A CMS template coded in velocity

This has equal parts Javascript and HTML. I use AUI, jQuery and a cocktail of them both wherever I feel the best of both worlds can be had.

My CMS template basically has a bunch of javascript at the top that is pulling in relevant fields from the structure.

The javascript is followed by some very tight (and light) HTML markup peppered with bootstrap classes and some minute inline javascript I didn't care to get rid of.

A journal article using this structure and template

This is where the structure becomes concrete. I specify values for the fields in the backing structure. These are the values that will configure my application.

An auxiliary suite of servlets

This is a web application containing a suite of simple, focused HttpServlets that are wrapped by Liferay's magical PortalDelegateServlet. If you don't know what that is, definitely look it up.

These servlets let me sneak under the portal's authentication hood and examine various session data. I can test that the user is authenticated (via CAS). If my servlets decide that user is not authenticated (or authorized as the case may be), my CMS template can roll over and play dead.

A RESTful service layer

...powered by my preferred JAX-RS implementation, Jersey. Lots of API resources here for all the little (and big) operational units we need to execute. There are POJO's (for use by JAXB) and various utility classes.

Why use CMS when, really, this should be a portlet?

It IS a portlet. It is the Web Content Display portlet that Liferay gave us out of the box.

Yeah, yeah. But then you're tied to the configuration that the Web Content Display portlet comes with. Right?

Yes. Exactly. It's content. I like to call it - stares off into space thoughtfully, then snaps back in an epiphanic moment -  I like to call it application content.

Alright, wise guy, how do you configure YOUR Web Content Display portlet?

I TOLD YOU. The journal article I created above lets me populate all those fields in the backing structure. Those fields are what I rely on to configure my (not going to say 'portlet') application content. There's a meta-shift in thought here.

What about the JSR-286 portlet spec and the cool lifecycle of a portlet?

Dude. Liferay's Web Content Display portlet follows the JSR-286 spec. It lives that lifecycle. It's all that already. Except I don't care about those parts. What I've done is essentially coded up a Single Page Application into my CMS template instead of into the portlet JSP.

Okay. But why?

Because I wanted to use all that ajax goodness anyway. Why would I want to put that into portlet JSPs when I can talk to my REST layer directly from velocity-enriched HTML. It's done all over the place.

Besides, when we upgrade to Liferay 7, this application content won't need any special migration. It should (hopefully) be supported as part of the standard CMS upgrade. And then, if I want to avail of Senna.js to write a real portlet-aware SPA application, it will be a lot easier to port my REST-conversant javascript over to an SPA.

The end is met

The means are fair

Or so I think. I would love to hear from the larger community and have this approach taken apart. Only good can come from any constructive criticism.

In the meantime though, this is soooo liberating. Frees me up to divert all my Java into a rich, flexible REST layer.

And all my UI code is slimmed down to HTML5 + Javascript + CSS - exactly what it ought to be.

Like I said: I've been busy building web application content.