Content-driven applications: A Marriage Between CMS Templates and RESTful services

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.

Parts of my web application

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.

Now, for the over-dramatized monologue.

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.

Blogs
Hi Javeed,
thank you for an interesting new view on CMS/Small portal apps. I'm looking forward to try that emoticon After first reading, several questions comes to my mind. (And maybe some code example would help here. ) One of them is: how you keep consistency of the two pieces (CMS structure/template and plugin with backend REST services)? I understand the great flexibility of UI layer here, but what about versioning and consistency with backend plugin. When you change the spec a bit you need to do both, deploy new version of backend and do some manual change in the CMS. (Or keep the structure/template/article within the backend plugin, but then the flexibility is not much different form JSPs.) Is the move form JSP to VM really worth is so much?
The second thought is about Liferay 7 migration, shouldn't be botch ways (MVC portlet/CMS articel) similar and easily upgradable without much effort?
Please take these thoughts just as friendly discussion kick-off or my ask for clarification. I always really like such a new ideas and thank you for the article again.
Hi Gustav. Your comment does a great job of pinpointing one of possibly many engineering concerns with the approach I outlined. My intent in using the term 'web application content' was really to foster discussion around thinking about our CMS Template as a versionable entity.

Liferay already supports content versioning. If we were to also version templates (and structures), then providing a version ID to our back end REST application is akin to telling it: "by the way, here's the version (or versions) of the front-end template you are compatible with". I really think a methodology could emerge here.

Regarding your comment on the move from JSP's to VM being worth it or not: we are wading into a mobile-first implementation style. We have some very talented UI developers. The reality is a JSP file is not the same to them as a velocity template. The latter is far less daunting to UI developers and way easier to experiment with. Switching to velocity templates IMO makes for less time spent by server side developers (me) in supporting the tasks of UI developers.

Thanks so much for your insightful comment. Glad for the critique. Looking forward to read more from you.