Resources 1.1(.1) plugin released

After a frantic 12 hours or so of coding and debugging, I managed to release version 1.1.1 of the Resources plugin for Grails today.

It was meant to be 1.1 but there was a bug that needed fixing immediately after releasing so 1.1.1 is where we’re at. This version is tested with Grails 1.3.7 and Grails 2.0 RC1 which is set to drop this weekend.

What’s new in this release of Resources?

Well aside from some useful bug fixes there’s a few interesting changes:

1. If you forget to include r:layoutResources tags, you will get an error in the console. The error may or may not display in the browser currently depending on whether you used site mesh layouts or not. We may be able to improve this in future. This means that people who wondered where their JS code was disappearing to after installing Resources into a 2.0 app will now get an error telling them that they need to add r:layoutResources.
2. There is now support for laying out arbitrary dispositions by passing a “disposition” to the r:layoutResources tag. This means you can position sets of resources wherever you like in the output, using multiple dispositions. Currently this is only relevant for JavaScript but in future we should be able to support images so that you can e.g. have a bunch of “preloaded” images that are hidden in the page somewhere.
3. The integration with Grails 2.0 has been “finalized” now. The ResourceService has changed to a “grailsResourceProcessor” bean, and all g:javascript invocations result in called to r:require or r:script as necessary. The default layouts in 2.0 now use layoutResources and a default “application” module exists in new projects.

There are still some outstanding important bugs that I will endeavour to fix soon, as well as improving the error reporting on all fronts.

Enjoy!

How we use Weceem CMS at NoticeLocal

We have an online notice boards startup called NoticeLocal that we’ve written with Grails.

In my experience over the years it became obvious that one of the major pain-points of using Java to deploy web apps is the hassle of updating a bit of content here or there, replacing an image – those kinds of things that should be simple but aren’t. Also a lot of the time this stuff is not subject to the same strict versioning processes that we are using for our code.

As you may know I am paid to work on the Weceem CMS plugin and application, that is also Grails based.

For NoticeLocal I decided that it would suit us well to use an instance of Weceem CMS running on one Tomcat, to supply the marketing/PR site for the service, as well as the multi-language content for UI elements in the main application.

It turned out this was really easy to do, even though Weceem currently has no API to speak of.

To do this we:

1. Have a vanilla WeceemApp WAR running in one Tomcat instance
2. Have our NoticeLocal application WAR running in another Tomcat instance
3. Wrote a trivial taglib in the NoticeLocal application to retrieve content nodes from the CMS instance using vanilla HTTP requests to URLs with a predefined prefix, and stores the text them in a local ehcache.

So, in Weceem we have a bunch of HTML content nodes that represent different elements of the main NoticeLocal app’s UI – we have several different Weceem templates that these different nodes use – e.g. one for side panels, one for full page content (but laid out inside the main NoticeLocal app sitemesh layout, and one for inline UI messages such as those shown on demand when the user performs some action.

So in our NoticeLocal application we use our taglib to render a “remote CMS message” in our pages using the not-so-well-known Grails/SiteMesh g:applyLayout tag that, just like Grails layouts, will parse out the body of the content that we’ve cached, and render it in situ.

Oh, and for bonus points we use a simple regex replace to give us GSP-like variable expansion when rendering the content from the local cache, so we can perform variable substitutions like ${userName} – so you can write that in a HTML node in Weceem, and by the time the NoticeLocal app renders it, it has your name in it.

At any point we can log into the CMS, update some UI message, and when the cache expires the users see the new updated stuff. No app redeploys.

Oh, and because its in a CMS we solve the hard problem – i18n translations of rich content with styling, images etc.

In a nutshell, it’s great!