Grails Rocks » Grails http://www.anyware.co.uk/2005 Grails, Apple, usability and world stuff Fri, 27 Jan 2012 13:52:31 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Resources 1.1(.1) plugin released http://www.anyware.co.uk/2005/2011/10/21/resources-1-1-1-plugin-released/ http://www.anyware.co.uk/2005/2011/10/21/resources-1-1-1-plugin-released/#comments Fri, 21 Oct 2011 00:31:07 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=1094 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!

]]> http://www.anyware.co.uk/2005/2011/10/21/resources-1-1-1-plugin-released/feed/ 5 Optimising your Application with Grails Resources Plugin http://www.anyware.co.uk/2005/2011/09/12/optimising-your-application-with-grails-resources-plugin/ http://www.anyware.co.uk/2005/2011/09/12/optimising-your-application-with-grails-resources-plugin/#comments Mon, 12 Sep 2011 20:16:04 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=906 It’s been nearly a year since we first announced the Resources framework for Grails. It’s about time we looked at some of the more advanced features that it provides so that you can make the most of this very powerful plugin.

The start of this article will go over some of the basics again, as they are a prerequisite for understanding the more advance topics covered later in the piece.

Recap: What is Resources framework for?

It solves the growing problems around application and plugin static resources. Your CSS, JS and other files have dependencies on each other, and must load in the correct order. You also want to optimize these so that your application loads quickly and caches well for your users.

It provides a way to declare your resources, their dependencies, and a processing chain to modify the resources and response headers to perform all manner of tasks such as bundling multiple resource files into one file, zipping the response, applying long-term client-side caching, or compiling Less or Sass files to regular CSS on the fly.

Where do I start?

First you install the “resources” plugin. To actually see some magic happening you probably want to also install the cached-resources and/or zipped-resources plugins also, but this is not a requirement.

Then you declare some resources in your app, or pull some in from a plugin that supports Resources. Let’s start by declaring a resource that exists in your application, say main.css. To do this you create a file in grails-app/conf/ with a name that ends in “Resources.groovy“. So we might create AppResources.groovy and use the DSL to declare the resource:

This is a module declaration. For full details see the Resources documentation, but in essence this declares a resource module called “common” and it has one CSS resource in it, the file supplied by your application in web-app/css/main.css, and on JS file.

So far, so good. Now you need to pull this resource into a page. To do this requires using some Resources tags.

Using resources in your pages

There are two main tags involved in using resources, with some others that provide extra features. The main two are r:require and r:layoutResources.

The r:require tag tells the framework which resource modules the current GSP requires. The framework will make sure that all the resources declared in those modules are pulled in in the correct order.

To achieve this, you need to include r:layoutResources tags in your <head> and <body> sections. Typically you do this in your SiteMesh layout. You use two calls because one will render the resources that you need to link to in the <head> section of your page (all your CSS, and some of your JavaScript, maybe some favico or iPhone icons). The other goes at the end of the <body> of your page, to render any “deferred” resources, which is usually just your JavaScript code.

So here’s an example of a Grails Sitemesh layout using these tags:

Here you see that you still use the normal Grails sitemesh tags to layout the head and body. These provide the route for you GSP page to actually affect the output, including the output of the Resources plugin’s r:layoutResources tags. That’s because your GSP will call r:require and r:script tags something like this:

This GSP is set to use a Sitemesh layout like the example one given earlier. It uses the r:require tag to say that this page needs the “app” resource module. Using this information, the r:layoutResources tags will render links to all the CSS, JS and other resources of that “common” module, in the correct places.

This means that some may end up in head, and some may end up in body. Remember that we invoked r:layoutResources twice, once in each location? Well, that’s why.

What is this “disposition” stuff?

The disposition of a resource tells the framework which part of the page it belongs – its a form of arbitrary grouping. The default dispositions supported are “head” and “defer” but in fact resources can define any disposition they like – and this can be useful for declaring resources that are not rendered by the normal layoutResources calls (more about this later).

The framework applies a default disposition based on the type of the resource – so CSS always defaults to “head” but JavaScript always defaults to “defer”, so that it runs only when the rest of the page has loaded. Images and icons are also supported to represent favicon and iPhone icons, which render in “head”.

Resource modules usually contain multiple resources and the main reason to specify a disposition when declaring a resource is to force JavaScript to load in the <head> section of the page. To achieve that you just update your resource declaration to include a “disposition” attribute:

Now your page will load with jQuery in the head section, with no code changes to your layout or GSP!

Dependencies

So far, so good but how do we control the order of resources when they are pulled into the page? How can I make sure that my application JS or CSS code always loads after the JS and CSS from a plugin that I’m using?

This is where Resources dependencies come in. There are two simple rules

  1. Resources from a given module are loaded in the order they are defined in the module
  2. Resources from modules are loaded in module dependency order

The first rule ensures that when you declare resources you can intuitively see which CSS or JS loads before another.

The second rule uses the “dependsOn” method in module declarations to list the names of other resource modules on which the module depends. Those will always be loaded before the module that depends on them. Here’s an example declaration that alters our specimen module to depend on the jQuery plugin’s query module instead, and jQuery UI:

Notice that we have specified both jQuery UI and jQuery in the dependsOn. We don’t need to. However notice that they are also declared in the “wrong” order. This is to illustrate that the order you use here is not important – the ‘jquery-ui’ module declared by the Grails jQueryUI plugin depends on on ‘jquery’ (provided by the Grails jQuery plugin) as well – so it will always make sure that is loaded first.

As your application does not define those two modules, you would need to install the Grails jQuery-UI plugin – or define them yourself. Including the jQuery-UI plugin automatically pulls in the jQuery plugin for you, because of Grails’ transitive plugin dependencies. TheResources framework was designed to work hand in hand with the other Grails dependency mechanisms.

So now you have done this, you still have no changes to make to your GSP! It still just requires the “common” module. Notice how this has decoupled your GSPs and layouts from the details of the resources that they need. This is an important feature that gives you great scope to modularise your resources, and even have page-specific modules if you like that contain nothing other than dependencies themselves:

With this, an edit.gsp could just r:require the “editPage” module and never care about the explicit details of what is required.

Dealing with your ugly inline Javascript

You already know that inline Javascript is pretty horrendous, but some things are just plain shameful and yet we can’t help ourselves. Frequently you want to write a Grails taglib that simplifies using a JS library and to do that it must render some code inline when the tag is invoked.

With Resources you can trivially throw this JS code around to wherever you like. You can have the code render in <head> or at the end of the body, and it will automatically do so after loading the resources that the page depends on. To do this you just use the <r:script> tag instead of a normal <script> or <g:javascript> tag:

In this example the script code specified in <head> does not run immediately. The r:script tag also uses “disposition” and the default is “defer” so you will find that the alert only pops up once the rest of the page has loaded, and the HTML source will show the <script> tag at the end of the body, after all other deferred JS code has been pulled in.

All such fragments in the same disposition are concatenated together, so you don’t get a long list of <script> tags.

To force a fragment of inline JS to execute in <head>, just add disposition=”head” to the r:script tag invocation.

To write your own taglibs that generate code in this way, you just output the result of calling the r.script(attrs, Closure) tag from your tag.

Linking to images

Images often need to be optimised or set for long-term caching. However you don’t normally need to declare them in modules. To render images correctly you should use the <r:img> tag anywhere in your pages as you would and HTML <img> tag. All you do differently is supply a uri or dir/file attribute to tell it where to load from. Other attributes are passed through:

That’s all there is to it.

There are however some extra tricks you can pull. Any tag attributes specified in a module resource declaration are honoured when rendering the link. As such this means that you can specify your width & height values if you declare your image – and never have to specify them when rendering links:

Now any r:img links to that logo will automatically include those attributes in the output. Notice that we had to include the disposition “image” which is not a predefined disposition – it is just anything other than “head” or “defer” to prevent the image being rendered by the r:layoutResources tags.

Bundling: combining files to reduce the number of requests

Page load time is a combination of many factors. Those that you can control from your application itself include how many requests are needed to load your page and whether you load resource before or after your HTML content.

To reduce the number of requests made, you need to combine one or more resources into a single file. This is called bundling and what you do is tell Resource which files can be bundled together. This is usually dependent on how your application uses the code, and inevitably requires some compromise.

For example you could bundle all your resources into one file across your entire app – resulting in just one CSS and one JS file for the entire site. With aggressive browser caching this could yield good results, but if you have a few hundred KB of code in these files it could mean it takes a long time for people to see your site the first time they visit or empty their cache.

To specify the bundle that a file belongs to, just add the “bundle” attribute to resource declarations. The Resources framework will not bundle together resources that are incompatible: different content types, or those with differing “attrs”. For example CSS with media=’print’ will not be bundled with screen media.

It does however allow you to bundle resources across module boundaries. This is important as you will see shortly. It also automatically bundles using the module name by default, and maintains separate bundled files for head and defer dispositions automatically.

That is a lot to take in, but it basically means you don’t need to worry about anything.

Just set the bundle attribute:

Here the main.css, which previously might have auto-bundled into bundle “common” if there was more than one resource in the module, will now be bundled into bundle “core”.

The difference has no effect for now, but what you can do is override the module declarations that came from the jQuery plugins and make them go into the same bundle. To do this we use the “overrides” mechanism to change the properties of the resource modules supplied by the plugins. We can call the defaultBundle method to change the default used by them:

Now all the modules will throw their resources together, and you will find your page (again with zero GSP changes) is now pulling in just three files: bundle_core_head.js, bundle_core_head.css and bundle_core_defer.js

Changing how links to resources are rendered

Under the hood, the r:layoutResources tag uses the r:external tag to render links. The r:external tag is a smart tag that writes out the “right kind” of link for a resource. So for JS files it renders <script src=…> tags, for CSS it renders <link href=…>, and so on for favicons and a few other types.

The key thing is that you can pass any other attributes to r:external and they will pass through to the output. It so happens that r:layoutResources pass the “attrs” Map defined in your resource declaration when calling r:external for that resource. This means you can pass any extra attributes you like to the declaration and they make it to the output.

A typical usage for this is to specify media:’print’ on a CSS resource, because the default for this is “screen, projection”:

Note that if you specify these extra properties, those files will not be bundled with others, as by definition this isn’t going to work out well for you.

Wrapping the link in some other code. AKA MS IE workarounds

The resource declaration can also supply some wrapper markup that is used to render the link, with the generated link being passed in as a string. You normally use this to wrap a resource such that it is commented out for all browsers except MS IE:

The wrapper Closure is passed the link text as an argument. You are then free to pre/post-fix it with anything you like.

Linking to specific resources without using the dependency mechanisms

On occasion you may need to link directly to a resource that is handled by the framework, without using r:layoutResources or r:require.

To do this you can use r:resource to get the URL of a resource, or r:external to create a link to it. You can use these to generate absolute links to those resources, for example in an HTML email.

These tags accept the regular uri, url or plugin/file/dir attributes. The r:external tag also supports a “type” attribute to give it a clue what kind of link to render if it is not obvious from the file extension.

Overriding resources from plugins

Plugins that expose modules normally do the right thing, but sometimes you might need to supply different content for a given file, or change some of the tag attributes or the bundle used. To do this you use the overrides mechanism shown earlier in the defaultBundle example.

The “overrides” closure lets you specify new values for some of the module defaults for a given module, but also lets you tweak individual resources if they can be addressed uniquely. Developers must add an “id” attribute to the resource when it is declared for this to work:

This changes the bundle on just the resources with id “js” in the original jquery module. There might be one or more resources with that id in the module. Resources in other modules are unaffected.

For full details of what you can override, please see the Resources plugin documentation.

Using r:require in GSP fragments

Using g:render to render GSP templates to build up your pages is a powerful technique. What you may not have realised is that you can completely modularise these templates now because the enclosing GSP no longer needs to know what libraries they need.

Yes, you can call r:require at any time in GSP rendering – including inside nested GSP templates – and the dependencies of your code will be stored along with your request and the resources all tallied up when the r:layoutResources called in your Sitemesh layout execute.

The only pre-requisite is that your r:require must be invoked before the corresponding r:layoutResources that you’d like to use to render it.

Picture how easy it is now to create portlet-like user interfaces where only the resources needed by UI elements displayed to the user will be loaded, and when they are they will be optimised. The portlets they have not installed or disabled will not load their resources if you do not render their GSP template.

Dynamic requirements

It is important to realise that the r:require tag can support normal GSP EL values in the modules list attribute. This brings great power because you can change the code pulled in by a page at runtime. For example you can make yourself a trivial per-user theme-switching system by storing the name of the theme they want to use in the session, and using a tag like this:

This will locate the theme module and all its dependencies with no further coding.

You could even switch the entire JS library and supporting code used by your plugin’s UI so that, for example, the user could choose between jQuery UI or YUI, or their own implementation.

Including common resources in your layout

Most likely you have some resources that are used in all pages using your Sitemesh layout. This is no problem because you can call r:require inside your Sitemesh layout, with the same proviso as “Using r:require in GSP fragments” – they must be invoked before the r:layoutResources call that would render them.

This means that in practice your individual GSP pages are likely to have only one or two module requirements as the rest is handled by the Sitemesh layout.

Patterns for plugin authors

Here are a few emerging patterns for plugin developers to heed when supporting the resources plugin.

  • Specify id attributes on your resources when declaring them, to maximise the user’s opportunity to override specific details
  • Avoid monolithic modules, opting were possible to separate out functional areas such as the jQuery UI theme being separate from the jQuery UI code. This gives developers more flexibility. Obviously you must maintain correct dependencies between these
  • Put “development” un-minified versions of resources in “<yourmodulename>-dev” modules, so the user can pull in un-minified versions on demand, per-environment if they wish
  • Do not specify the bundling of your modules – at most use defaultBundle. No per-resource bundle attributes. Let the developer control this easily by overriding your defaultBundle settings in each module.
  • Use module names prefixed with the name of your plugin followed by a hyphen i.e. “jquery-main”, “myplugin-theme”, “acmeplugin-ui-styling”

Summing up

All the things we’ve tackled here are core Resources framework features – no extra plugins are required. The resource mapper that performs bundling is even built into the framework.

The real fun starts when you install some of the other mapper plugins – they may be renamed, re-encoded or even compiled from one form into another. It all happens at startup for declared resources, and at runtime for ad-hoc resources. Once it’s been done it is stored on disk on the server in that state and no more processing is done.

I hope you have fun with the Resources framework!

There are some nice refinements and maybe some new features coming in point releases at the time of writing.

]]> http://www.anyware.co.uk/2005/2011/09/12/optimising-your-application-with-grails-resources-plugin/feed/ 16 How we use Weceem CMS at NoticeLocal http://www.anyware.co.uk/2005/2011/02/15/how-we-use-weceem-cms-at-noticelocal/ http://www.anyware.co.uk/2005/2011/02/15/how-we-use-weceem-cms-at-noticelocal/#comments Tue, 15 Feb 2011 21:24:01 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=782 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!

]]> http://www.anyware.co.uk/2005/2011/02/15/how-we-use-weceem-cms-at-noticelocal/feed/ 8 Smart ETag and Last-Modified handling with cache-headers plugin http://www.anyware.co.uk/2005/2010/10/26/smart-etag-and-last-modified-handling-with-cache-headers-plugin/ http://www.anyware.co.uk/2005/2010/10/26/smart-etag-and-last-modified-handling-with-cache-headers-plugin/#comments Tue, 26 Oct 2010 15:30:05 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=740 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.

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.

]]> http://www.anyware.co.uk/2005/2010/10/26/smart-etag-and-last-modified-handling-with-cache-headers-plugin/feed/ 2 Javascript and CSS frameworks in Grails plugins http://www.anyware.co.uk/2005/2010/04/26/javascript-and-css-frameworks-in-grails-plugins/ http://www.anyware.co.uk/2005/2010/04/26/javascript-and-css-frameworks-in-grails-plugins/#comments Mon, 26 Apr 2010 20:38:24 +0000 Marc Palmer http://www.anyware.co.uk/2005/2010/04/26/javascript-and-css-frameworks-in-grails-plugins/ 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…

]]> http://www.anyware.co.uk/2005/2010/04/26/javascript-and-css-frameworks-in-grails-plugins/feed/ 1 My JAX London 2010 talk now online in video form http://www.anyware.co.uk/2005/2010/02/25/my-jax-london-2010-talk-now-online-in-video-form/ http://www.anyware.co.uk/2005/2010/02/25/my-jax-london-2010-talk-now-online-in-video-form/#comments Thu, 25 Feb 2010 14:29:16 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=692 I delivered my talk “Yes you CAN use Grails” yesterday at JAX London 2010, and it was well received. Unfortunately nobody was videoing it, and as the slides are “Presentation Zen” style you won’t get much from the official slides from JAX. It talks about Grails basics and how Grails is the perfect fit for existing Java development shops, and the things you need to know to make it possible to use it in your workplace. Well, at least you can try.

So I recorded myself doing the talk here at home and have uploaded a screencast of it all for those of you who are interested. Its not so good the second try – you had to be there for the best version :)

Click the thumbnail to download the MOV. Its about 47 minutes. Its probably going to cost me a fortune having it on Amazon S3!

Also available as a torrent.

People interested in making the case for Grails may be interested in an older post of mine that I’d completely forgotten about – “10 common misconceptions about Grails”.

]]> http://www.anyware.co.uk/2005/2010/02/25/my-jax-london-2010-talk-now-online-in-video-form/feed/ 6 Weceem 0.8 Released – Highlights and background http://www.anyware.co.uk/2005/2010/01/12/weceem-0-8-released-highlights-and-background/ http://www.anyware.co.uk/2005/2010/01/12/weceem-0-8-released-highlights-and-background/#comments Tue, 12 Jan 2010 14:01:02 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=670 I’ve just managed to push out version 0.8 of the Weceem CMS for Grails.

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.

]]> http://www.anyware.co.uk/2005/2010/01/12/weceem-0-8-released-highlights-and-background/feed/ 4 …and another Grails plugin http://www.anyware.co.uk/2005/2009/09/25/and-another-grails-plugin/ http://www.anyware.co.uk/2005/2009/09/25/and-another-grails-plugin/#comments Fri, 25 Sep 2009 17:14:26 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=561 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.

]]> http://www.anyware.co.uk/2005/2009/09/25/and-another-grails-plugin/feed/ 0 I’ve released another Grails plugin http://www.anyware.co.uk/2005/2009/09/18/ive-released-another-grails-plugin/ http://www.anyware.co.uk/2005/2009/09/18/ive-released-another-grails-plugin/#comments Fri, 18 Sep 2009 13:01:05 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=556 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.

]]> http://www.anyware.co.uk/2005/2009/09/18/ive-released-another-grails-plugin/feed/ 10 Development is easy. Creating product is hard. http://www.anyware.co.uk/2005/2009/09/17/development-is-easy-creating-product-is-hard/ http://www.anyware.co.uk/2005/2009/09/17/development-is-easy-creating-product-is-hard/#comments Thu, 17 Sep 2009 16:47:33 +0000 Marc Palmer http://www.anyware.co.uk/2005/?p=552 I’m working very long hours at the moment. By day I work on Weceem CMS and by night I am acting as the architect and producer of a new web service that I am developing with some friends.

Of course the web service is being built with Grails – it would be insane to use anything else! Chris our developer is doing an excellent job – Grails is massively empowering. In the timescale we’ve been working to an amazing amount of stuff has been achieved – even when some of it is being learned on the job.

Oh and of course the core idea is there but the details are being fleshed out as it is developed, but Grails reduces the pain for Chris as changing direction on some features is not as heartbreaking as throwing out weeks of work on thousands of lines of code.

Our designer Pat is also working well with editing GSPs directly, something new for her which she is enjoying, along with learning the joys of Blueprint CSS and jQuery UI.

However, what was obvious to me before starting this project, is painfully obvious to me now. Modern tools like Grails take the classically hard part of making a software product and turn the problem upside down.

We don’t spend time fiddling around with config and trying to glue various tech together, writing reams of bean accessors and lame JDBC code etc. – we spend all our time trying to meet the challenge of creating an application that really makes sense to users, hides all the technical detail – while providing features that a few years ago would have been considered very low priority due to the work required to get even the basics off the ground.

Expectations of modern web apps, especially the expectations that come from ourselves as designers and users of such services, are very high.

This is however a “high quality problem” compared to chipping away at a massive mountain of code just to get something half-assed ready, and deferring all the parts that are important and useful to end users (and hence ultimately the business) until later.

Time is of the essence. Grails cuts out maybe first 3 months of dev, and we focus on the business problems.

It’s a no-brainer in that sense.

]]> http://www.anyware.co.uk/2005/2009/09/17/development-is-easy-creating-product-is-hard/feed/ 3