Smart ETag and Last-Modified handling with cache-headers plugin

Smart ETag and Last-Modified handling with cache-headers plugin

Posted by: on Oct 26, 2010 | 2 Comments

I’ve been working on the next release of Weceem CMS these last few weeks and one of the issues to tackle was that Weceem was not setting any of the useful response headers used by browsers and intermediate proxies/caches.

Javascript and CSS frameworks in Grails plugins

Posted by: on Apr 26, 2010 | One Comment

The Weceem CMS plugin for Grails uses the Blueprint CSS framework, jQuery and jQuery UI Javascript libraries. As the Grails plugin marketplace continues to mature, other plugins will have more polished user interfaces or reusable tags that require certain libraries.

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…

…and another Grails plugin

Posted by: on Sep 25, 2009 | No Comments

I have released version 0.1 of Taxonomy plugin for Grails.

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.

I’ve released another Grails plugin

Posted by: on Sep 18, 2009 | 10 Comments

Witness the power of the bean-fields plugin for Grails!

<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 0.1 to 0.2 – changes under the hood

Posted by: on Aug 20, 2009 | No Comments

We released Weceem CMS 0.2 just before I went away on holiday a couple of weeks ago, so I haven’t had time to write anything about it until now.

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.