Version 0.6 fixes a bunch of bugs related to rendering fields for nested property paths e.g. propertyName=”book.author.firstName” and introduces support for list / array properties eg “book.authors[3].firstName” (This was really quite painful to implement!). Radio groups are working properly now, and test coverage much improved – thanks to contribs from Antony Stubbs.

It also adds a user-definable threshold for whether a radio group or select list should be used for a field with an inList constraint.

Full list of resolved issues is here.

Related posts:

1. Weceem 0.8 Released – Highlights and background

This is a pretty cool if slightly unglamourous release because it has focussed on some performance and security stuff – oh and compatibility with the latest and greatest Grails 1.2.0 release.

Let me first apologise for the ropey typography on weceem.org – we haven’t yet had the time/resources to fix up the CSS styles so things are a little ugly in places. We will fix it as soon as we get time!

Anyway, we added a security policy. This is a groovy script (currently only loaded once at startup) that lets you define what different users can do. This uses a DSL that lets you declare roles and then say what they can do in different spaces, including whether they can admin the space, edit/view/delete/create content, and even do this by URI requested. (see more info and example here)

Because we believe strongly that Weceem should not force you to use a particular authentication library, we had to decouple the policy mechanism from authentication. As a result these roles are completely uninterpreted by Weceem. To integrate and authentication system all you have to be able to do is provide the name, email, login and list of roles for the currently logged-in user. (an example here)

This has enabled some cool stuff in WeceemSecurityService which relies on the security policy. The service has utility methods for implementing our security logic, e.g. isUserAllowedToViewContent(Content c). For example in previous versions of Weceem you could not preview content if it was not in a publicContent status (eg not Published).

Thankfully from version 0.8, anybody who has the EDIT permission can view non-published content. the default security policy ensures that the default administrator account has EDIT permission, so you can preview away as much as you like. We plan future updates to this to allow the security policy to control who can manipulate different types of content, which will be really powerful for people using custom content types.

On the performance front, it became obvious that something needed to be done because the default “index” page installed by Weceem into new spaces was resulting in huge amounts of SQL queries for a single page.

This is because the page is made up like this:

• It pulls in a Template node for the styling
• It pulls in three Widgets for reusable HEAD section tags and header and footer
• The header widget iterates over all root content nodes and their children to render the menu with the wcm:menu tag
• The page itself links to various StyleSheet and JavaScript nodes to pull in styling and scripts – these are processed on separate requests but still add to the overall burden of the page

This can result in a lot of SQL chatter because we have (rightly so) made no effort to optimize this until now.

There are a couple of areas here that would make a big difference to the SQL traffic.

It is very important to realise that turning on the 2nd level cache in your Grails app’s GORM configuration does not magically give you major performance improvements. My understanding of this rather complex area (which frankly I found very disappointing) is:

• The 2nd level cache is only used for retrieval by object id. This is very important
• The query caches are used to cache the ids of objects returned for a given query
• Query caches are invalidated frequently by Hibernate if your model is not primarily read-only (and can cause some threading contention)

Luckily a CMS is pretty read-only in terms of number of requests that actually read vs update content, so the 2nd level cache is a good candidate for us here.

One of the major SQL hits for Weceem is resolving a URI to the ultimate content node to render. Due to the model we need to query for each part of the URI, so a request for /a/b/c results in three selects. So that’s an easy one – we added URI path -> content id caching (and some other smarts) into the ContentRepositoryService. So once content has been hit, it will always be retrieved by id in future, via the 2nd level cache.

Another issue is iterating over child nodes. This is less trivial. We are using some query caching but I have noticed that some of the criteria were not hitting the caches despite this – it needs further investigation. I think that due to the polymorphic nature of the content model and query cache invalidation issues, we may stop using these in future (think blog comments being submitted and invalidating ALL your caches).

Next up: Template and Widget nodes are GSP pages that we compile and evaluate. It turned out that due to issues in Grails GSP handling (that persist in 1.2 to my knowledge), there is no internal caching of compiled GSP classes built from non-Resource content e.g. strings. This results in a leak of PermGen space which ultimately results in VM collapse. So we now have a simple cache of compiled Template and Widget GSP pages, which is automatically invalidated as necessary when templates and widgets are edited, so it is transparent to the end user that there is a cache.

Finally with regard to performance, we introduced a nice simple wcm:cache tag. This lets you cache fragments of a Template/Widget and hence get major performance improvements. The cache is currently fixed at 1 hour, but its great for anything that pulls in remote content or for any expensive node iteration tags you might be using. More enhancements will come in future.

A couple of nice little things we squeezed in:

1. The Cancel button is back on the content editor screen, in the “right” place for Windows users (meh) and browsers (who made return always select the first button argh!)
2. The wcm:link tag now passes through any unused attributes eg class=”whatever”
3. We added a JS syntax highlighting script to the default space that you can use to render code snippets in your content easily

Anyway, please enjoy this release. Soon time to get started on 0.9 which should see the Blog functionality completed and other refinements.

Related posts:

1. Weceem 0.1 to 0.2 – changes under the hood
2. Javascript and CSS frameworks in Grails plugins
3. Development is easy. Creating product is hard.

The Navigation Plugin gives you site navigation menus by convention. You just define a property in your controllers to determine what actions are shown and in what groups.

Full docs here

There is even a default styling of neutral “silver” buttons that you can use, or override the CSS easily, or use tags to render the items any way you like.

Part of the motivation for this is that if we can establish a “de facto” convention for navigation info, then plugins will be able to use it, to have functionality that just automatically “pops up” in your existing application.

Anyway now when you are prototyping your apps you can just add “static navigation = true” to your controllers, and add <nav:render/> to your GSP layout… and away you go!

Enjoy!

Related posts:

1. Weceem 0.1 to 0.2 – changes under the hood
2. I’ve released another Grails plugin
3. Weceem 0.8 Released – Highlights and background

Actually its far from crappy already.

I have developed this partly as part of my work for my generous client Historic Futures Ltd. who agreed to open source this.

I plan to continue improving and maintaining it personally. It’s surely a bit rough around the edges but the benefits should be pretty obvious to those who use it.

So what are you waiting for? Run:

See the documentation

…but in a nutshell it is HTTP testing with HtmlUnit under the hood but the rest is pure groovy smarts, leveraging standard JUnit.

Example:

What’s special about this?

1. Simplicity and “elasticity” by default = less fragile functional tests as a result
2. Simple compact DSL/methods to learn – it tries to “do the right thing”. Let’s face it writing tests is really boring.
3. Ability to get/post directly without browsing to a page first. eg REST testing
4. No .properties configs

…and one more thing URL stacktrace. When a test fails the report includes a stack of the URLs at the point of failure. The xxx-out.txt file contains request parameters+headers, content received etc. This feature will be expanded in future to allow a proper request/response chain autopsy.

Caveats – things I definitely want to sort out pronto:

• currently test output is a bit ropey, I would like to do much nicer stuff with custom output xml and rendering
• no simple way to set post body
• no simple way to parse out json/xml responses yet

All this and more will come, with your support! Contribs also welcome!

ENJOY!

No related posts.

To install the plugin, which adds support for rendering the mail body from a GSP from within a controller, service or job, run: grails install-plugin mail

Full docs for the mail plugin are here.

To view the “Using the Grails mail plugin” screencast, click on the thumbnail or go to the fledgling “Grails Rocks” page.

This is the first Grails Rocks screencast, but I hope to do many more. The next one is already planned, for the forthcoming release of the Email Confirmation plugin – which was dependent on this mail plugin 0.4 release.

Related posts:

1. …and another Grails plugin
2. I’ve released another Grails plugin

Anyway, the fixes allow you to render email body GSPs where the GSP may live in a plugin, or be overriden by your app. To do this, you have to specify the plugin name when rendering the body of the mail – this is required because there’s currently no way Grails can know where the view might be as the contents of plugin view trees are not merged with the app view tree. I can see scope for a future improvement in Grails core, to add all plugin view paths to the resource search paths during development, and shipping a single merged views/ tree within .WAR files built by Grails.

So here’s how you render a mail body from a view in a controller with grails-mail installed:

This will try to locate the view in:

<app>/grails-app/views/something/mailbody1.gsp

but if it can’t find it, will try:

<app>/plugins/my-great-plugin-<vernum>/grails-app/views/something/mailbody1.gsp

Also these commits fix GSP taglibs in email bodies. Previously they’d appear in the HTML response of the controller ooops… now they appear in the body of the mail as expected.

Related posts:

1. I’ve released another Grails plugin
2. Weceem 0.1 to 0.2 – changes under the hood