This obviously needed improvement, and this tied in well to work I had already done on the small but beautiful Grails cache-headers plugin.

The problem: with a CMS you generally can’t make the client cache any content, not without some config for the CMS author/administrator to specify how long to cache it for – this is a problem we will tackle later. However at the very least you want to avoid re-generating content when requested if the client already has the same content.

The solution: Implement ETag and Last-Modified handling correctly so that when you receive requests with If-None-Match or If-Modified-Since you can return “304 Not Modified” if the content is the same as that the client last downloaded. This can give you major improvements in client response time and also server load, even in applications with highly dynamic content.

The thing is, implementing this from scratch in every Grails controller action you have is rather dull.

So in steps the new withCacheHeaders method in the Cache-Headers plugin. This method works a little like Grails’ excellent withFormat method, using a simple DSL to specify:

• How to generate the ETag for this request
• How to calculate the Last-Modified date for this request
• How to render the response, if we need to do this because the content has changed since the client last downloaded it.

Using this information that you provide, the cache-headers plugin will automatically work out if it can return “304 Not Modified” or if it has to render your response for you.

Here’s a working example from Weceem’s content rendering controller:

As you can see there are three “method” calls inside the withCacheHeaders call: etag, lastModified and generate. You simply implement these and the plugin handles the rest.

In the “generate” closure we’re also calling the lastModified method added to controller actions by the cache-headers plugin. This lets us easily set the Last-Modified header of the response, and then we make a token effort at setting client/proxy caching headers with the “cache” method. This will be subject to later refinement.

For more details see the docs.

This raises an ugly prospect: a new resource dependency problem. Only unlike java dependency problems this is worse as you end up with multiple copies of resources in your app, even if they are the same version because plugins will typically bundle the resources themselves. Your app may add some of these too and your site becomes slow to load or experiences failures related to clashing library versions.

There is however a staggeringly simple solution to this: lightweight Grails plugins that contain the resources.

Thanks to Grails’ automatic dependency resolution we (the grails community) can just create plugins to wrap up each such library and then we just make any apps or plugins that require them depend on them by installing the library plugin or adding it to the dependsOn clause of other plugins.

An important caveat here is that the library plugins need to use version numbers matching the version of the library they encapsulate. Then if you want jQuery 1.4.2 you depend on/install grails-jquery version 1.4.2 or higher. The grails-jquery plugin authors have already done this.

These plugins should implement a simple tag called “resources” in an appropriate namespace e.g. or .

I strongly believe that such plugins should NOT include other tags or more heavyweight tags wrapping up library features – do that in another plugin e.g. “grails-jquery-tools”.

This approach does provide new challenges for optimizing static content – minifying JS and CSS and including only required modules from a larger library remains awkward as it is today with non-dependency solutions.

Ultimately I think we need smarter solutions than those currently in use to solve this. I have some ideas forming…

This new plugin lets you add hierarchical categories (taxons) to any domain object in Grails.

Inspired by Graeme’s excellent Taggable plugin, this uses a similar underlying data structure but adds hierarchy and the extra querying methods you need to find any objects that have a given category or any of its sub-categories.

See the docs and examples here and and give it a try.

<bean:withBean beanName="form">
    <bean:field property="firstName"/>
    <bean:field property="lastName"/>
    <bean:field property="company"/>
    <bean:field property="email"/>
</bean:withBean>

This will render input fields of the appropriate type, with sizes set according to the fields’ constraints, select field items from inList etc. It also renders label tags, errors local to the field, and required indicators.

You can customize the markup used for all this stuff, so that you get a consistent and noise-free rendering of fields across all your GSP views.

Please do check it out and let me know if you have any issues.

Weceem is a CMS written purely in Grails, using Grails plugins as much as possible. It has some history at jCatalog AG who have worked on the code and core concepts in various forms for a while now, and for the last 10 months or so I’ve been helping them out with Grails approaches, architecture and a little coding.

We didn’t want to write another CMS just for the sake of it. Lord knows there are so many out there, its almost painful to write another. However we believe we can bring simplicity and novel functionality to the CMS space that is missing in other Java-based CMSes. (Perhaps this is the folly of all who re-invent the wheel?)

Release 0.1 was a line in the sand, whereas 0.2 includes some major overhaul. It took a lot longer to get to 0.2 than we intended, but there were some major changes behind the scenes, aside from bringing it up to Grails 1.1.1 compatibility and splitting it out into a Grails plugin and an app, so you can embed it in your own Grails apps or use it standalone.

Here’s a brief write-up of some of the changes we made, and why. There is also a short screencast that shows these changes here.

Reworking the admin UI

The admin UI desperately needed some love, and we want to move to a much more contemporary and less “Windows app” like feel. Something that is bright, bold and clear.

We also greatly simplified it, reducing the number of screens. We are for the moment at least using BlueprintCSS for the structural layout of the admin UI. It has been a major timesaver for us coders who, if we are honest are not the best cross-browser CSS designers.

What we’ve done so far with the admin styling is begin the migration away from the old UI. The work is by no means complete yet, and the UI will be more polished in time. We’re very much focusing on getting the bare bones functionality working well first before we do anything too fancy with the visuals.

Switching to jQuery and jQuery UI

A wide mix of tech was used in 0.1 for legacy/RAD/prototyping reasons, resulting in a fair amount of bloat, and slow page load times.

As a result we ditched all of the Dojo/Dijit/Dojox stuff that was there and complete rewrote the UI in pure jQuery and jQuery UI. Our code is wonderfully lean now.

We looked at all the libraries out there and decided on jQuery. Its “where its at” as far as we’re concerned. Unfortunately we have had to use a “non-core” tree table widget and some custom behaviours for the draggable content repository, which is currently a bit ugly in places – but it is a work in progress that improves greatly on the old tree UI.

We still have some cross-browser glitches eg badly floated button icons in Safari and a few layout “blow outs” that we will fix in time. Any help with these jQuery UI style issues would be much appreciated – I haven’t received any help on the jquery ui mailing list about the Safari icon issue in particular.

Dynamic content editor

In 0.1, which had effectively evolved from a prototype, each content type had its own controller and views for editing, with lots of duplication. Much of this was modified scaffolding, and we all know that while scaffolding is great for helping you to build a house, nobody lives in a house and leaves the scaffolding up once the work is done!

Extensibility of content types in Weceem is very important to us. So in 0.2 we introduced a dynamic editor framework. There is a single controller and view set for editing all content types in Weceem now.

We achieved this by using some convention properties on the content classes to declare which fields are to be presented in the content editor, and how they should be rendered.

Because of Groovy’s wonderful dynamic abilities and Grails taglib support, we are able to render any custom editor you may wish to use on a content field – you just have to supply a Grails tag that follows a specific naming convention, and use the correct name in the editor declaration of the field in the content class.

For example, rich html editing as used for the “content” properties of HTMLContent and WikiItem, is achieved by specifying the “RichHTML” editor:

static editors = {
    template(group:'extra')
    content(editor:'RichHTML')
    keywords()
}

The editor then invokes the editorFieldRichHTML() tag when rendering the “content” field of a HTMLContent node in the editor. Its as simple as that. We also have hooks for custom editors to pull in extra resources in the <head> section of the page, such as JS and CSS files.

We have grouping of fields into the “Extra” section, and perhaps more in future, and you can force the hiding of certain properties.

This mechanism works with inheritance, which we use heavily in the content model – although the details of precedence rules are yet to be finalized.

Reduced plugin dependencies

We removed our dependency on RichUI and a couple of other plugins, which were either not fully used yet by the CMS’s current features, or were providing unnecessary bloat.

In fact we don’t use any Grails plugins for JS-related UI work now, only the FCKEditor plugin for the rich editor for HTML editing.

Separation into Grails Plugin and Application

This was a bit of an upheaval what with all the refactoring going on too, but Weceem which was formally a Grails application is now 99% encapsulated in the Grails WeceemCMS plugin which you can install into your own Grails applications to instantly add a great extensible CMS with a ready to use admin interface.

The plugin is hosted in the central Grails plugin repository (eg: grails install-plugin weceem).

The other 1% of the original Weceem application functionality remains a standalone application that uses the Weceem CMS plugin and simply adds some config mechanisms for the DataSource, and adds Acegi security and a default content repository, a copy of the weceem.org site. Its literally a run-and-go CMS, the full source of which is under 250KB zipped!

The plugin has a very simple abstraction of security which may be subject to change in coming releases until we hit 1.0, but this allows the plugin to not care about what authentication and authorisation mechanisms you want to use. We simply abstracted this functionality into a service where you can inject your own handlers to obtain the currently logged in user id etc.

Navigation and extensible admin

More work remains to be done on this but we have utilized the Grails Navigation plugin for the admin menus, including the items in the Administration page.

What this means is that applications that use the Weceem CMS plugin can inject their own admin screens into the UI provided by Weceem. This is absolutely trivial to achieve with the navigation plugin, and exactly this approach is used by the Weceem application to add user management screens which are specific to the app, into the Administration screen:

class UserController {
  static navigation = [group:'weceem.app.admin',
    action: 'list', title: 'users']
...
}

Chowing down

Eating your own dog food is always recommended (who invented that phrase… who eats dog food anyway, I know I wouldn’t recommend it) and we do this in a big way:

1. Weceem.org is self hosted with Weceem CMS application
2. Weceem CMS application uses the Weceem CMS plugin, and proves that the abstractions work
3. The people that are developing Weceem are using it for real world sites other than weceem.org

Next up…

We’re already working on version 0.3 which should bring full blog functionality in, clean up some UI niggles and bugs and flesh out the Wiki functionality too – time permitting. Oh and more test coverage and functional tests. The gap to the next release has to be a lot shorter!

I’ve put together a quick screencast showing a quick run through the admin parts of Weceem from a developer perspective. You can download it here.

There’s a number of tweaks to Navigation Plugin, improvements and fixes for Functional Testing (G-Func), as well as some bug fixes for the Authentication plugin.

I’m not sure when I will get time to do these, but they are on my radar. Sadly one has to earn money and plugins don’t generate any (directly). I really want to work on these things but you know how it goes. Good will doesn’t pay the bills!

I was toying with the idea of “crowd-funding” updates to plugins, for specific iterations of plugins that users are willing to pay small sums for in order to get it turned out quicker. I think the model could work… eg 100 people pay $10 to get a new iteration of G-Func released. It could be a new model for open source..

The tools for collecting crowd-funding revenue are already out there for fundraising projects.

Anyway I hope to knock out a new nav plugin iteration in the next week or so, ditto for G-Func. I just can’t promise it