Grails Rocks » ui

Optimising your Application with Grails Resources Plugin

Marc Palmer — Mon, 12 Sep 2011 20:16:04 +0000

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 and 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 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 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 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

Resources from a given module are loaded in the order they are defined in the module
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 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

In this example the script code specified in 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

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

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 “-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.

The future of computing UIs – TV and touch tablets and OS X

Marc Palmer — Wed, 16 Sep 2009 21:40:37 +0000

I find it hard to imagine we will be plugging away at these cumbersome computers for that much longer, at least not for casual usage.

It is noticeable that Mac OS X and related apps are moving to user interface paradigms that will work much better than conventional UIs on (touch controlled?) TVs and multi-touch tablets.

Some examples of this growing trend:

Front row started it really
Several Apple apps with full screen modes. Especially the new quicktime X and its large transport buttons, iTunes/Front row with Coverflow, iPhoto with multitouch trackpad support
The new exposé screen layout, touchpad gesture and per-app exposé
Spaces – something that will prove MUCH more useful if every application is full screen, and effectively each Space is a single Application. Then Exposé sort of becomes the current spaces “zoom out”
Safari “Top sites” is, in my opinion, clearly targetted at touch (tablet) displays.
iTunes LP media format
This is the big one – iTunes “Home Sharing”. This is required to solve the problem of your TV/tablet as a media purchase platform. You will typically buy content at home on a TV/tablet and then expect it to be on your laptop and hence iPod.

So I expect, within a few years, for us to see a new paradigm at least for TV and tablets where apps run full screen and you swipe to switch application… and wonderfully simple UIs as a result.

If we can only do away with the keyboard, we might finally be rid of these rather old fashioned apps with lots of menus and shortcuts and yada yada.

An idea to give Grails tags “E.S.P.”

Marc Palmer — Mon, 19 Jan 2009 19:58:27 +0000

There exists a problem with all current JS UI plugins in that they produce HTML content that is peppered with inline Javascript and/or CSS. This is widely acknowledged as bad practice and greatly increases page load times.

This can be reduced to a problem of the inability for custom tags to define the contents of JS and CSS used by the current GSP page. This can be generalised to and inability for a tag invocation in a page to contribute to the production of any related content.

There is also a separate problem of taglibs invoked within a page body being unable to influence the content of the section of an HTML response. This problem could be solved by introducing a two-phase GSP page execution, but most likely this should be handled by external resources, eg .js and .css files added to te section via tags.

The solution is quite simple, but with some subtleties to make it truly rock.

In a nutshell, we use some generic taglib functionality to gather information about what JS and CSS (or other resource) information is to be gathered and served for the current page, and have a controller with a cache to serve it up.

What we’re doing here is exploiting the fact that the possible race condition of CSS+JS being loaded before the HTML is full loaded by the browser, is not going to happen to pages laid out by SiteMesh, and even for other pages will only be a problem for the first request (see workarounds for this later).

Introducing the concept of “The E.S.P. Plugin”

This plugin would provide a taglib and a controller, and either another tag, or a service (See below).

The taglib would offer:

This tag is used in the section of layouts or pages, to indicate that you want to pull in a resource. The group attribute is optional. If there is none the group will default to “${controllerName}.${actionName}”. This is how you control where resources are served up. You can have a resource per page, or you can be smarter and have them grouped in any combinations you like, eg a single CSS file but separate JS files. Some pages may even have more than one such inclusion:

...

This tag simple outputs a tag with the mimetype + relation set according to the “type” value, and a link to the ESPController action with params “group” and “type” and “template” – if there was a “template” attribute specified. There could be a URL mapping to prettify this to something like:

/esp/contactForm/js

Then we have another tag or service to store strings against the group and type, and to detect if such data has already been registered (to prevent tag slow-down for every request).

For example as a tag called as a method from UI taglibs:

if (!esp.has('contactForm', 'js',
       "grailsui.richtext.${attrs.id}")) {
    esp.store('contactForm', 'js',
       "grailsui.richtext.${attrs.id}") << "some text"
}

Whether this is a tag or service makes little difference other than convenience. The data would ultimately need to be stored in a cache in a service – the value returned from the store is a StringWriter that can be put in a local var and reused across multiple “<<” invocations.

The page-unique id is required to prevent the same content being cached more than once for that group.

Order of data stored must be preserved so they are written out in the same order.

Tags will use this form for writing out their JS or CSS, while they simultaneously – in most cases – also write out some vanilla and entirely unobtrusive HTML.

NOTE: There should be a form of store() that does not take the “group” parameter, only type and id. This would default to the last ‘group’ value used in the esp:resource tags in (which would be stored as a request attribute).

Next, the ESPController:

This controller would work by retrieving from the internal datastructure all the strings registered for the specified group and resource type, and then:

1) if there is no “template” attribute, simply render them out with a default content type based on the “type” stored

2) if there is a “template” attribute, it will render the GSP template and put all the strings into a list in the model that can be iterated in the GSP – so that you can have a base template and do any decorating you want

3) Set appropriate caching headers (probably subject to Config.groovy settings). Although this is not intended to be a substitute for high performance front end caching of the resources.

4) If there is a request for a group and resource type combination for which there is currently no data, we presume this is due to a request race condition or a first request with an eager browser so it either:

i) returns a “Server busy” or similar status code

ii) uses a filter to know when such a request has first been served (checking request attribute for groups and types used in the page), and have the /esp/ request for same groups+type “sleep” until the first request is complete.

iii) use a tag used at the end of the GSP/layout such that this sets a flag in the global data indicating that requests can now be served for the groups+types used in the page.

Hopefully this makes sense. In essence it is quite simple.

It also gives us a new feature – the ability to define “static” data used across different GSP pages and resources, and text fragments for reuse without . All it needs is an extra tag to get the content.

I have to say that I prefer option (i). Frankly I couldn’t give a damn about request zero

The Co-operative Bank online banking… again (!)

Marc Palmer — Wed, 14 Jan 2009 16:16:22 +0000

The uselessness of Co-op Bank’s online business banking is a long running saga on my blog.

The latest twist, which I noticed some weeks ago, is as follows. Previously lots of problems with CORBA_NO_RESOURCES errors coming back to you when you try to do stuff.

It doesn’t take an IT consultant to guess this means their servers are overloaded.

Which is why I am a little cynical when I see that they have changed all the payment reporting screens to default to show only payments from TODAY by default. Where you used to see a history of recent payments immediately, you always have to select a date range and do a report now.

Why cynical? Well you could argue that this was a cheap way to further inconvenience customers reduce load on the database systems.

Dear Co-op bank. I’m getting more and more people contacting me via blog comments saying how fed up they are. You are going to lose a lot of business if you don’t sort this out.

UI Widgets… oh for something pure Grails

Marc Palmer — Tue, 06 Jan 2009 10:14:10 +0000

I feel like there is a mismatch in the grails/rails opinionated software approach and the apparent lack of a de facto and impressive UI library for javascript based web-apps built with these frameworks.

Sure, Grails has more than its fair share of UI plugins. However they all pull in other libraries, and frankly not even Yahoo UI stuff looks good enough to me. Libs such as YUI are supposed to be skinnable but the docs on actually creating skins are non-existent.

Even without those issues, you have the thorny problem that choosing a UI widget library usually dictates what JS/DOM helper library your application will use. This is infuriating if say you have an investment and passion for library X (eg Prototype) but the best UI widgets use a different underlying library.

Mixing and matching libraries in the same app is extremely unattractive. Download times become a factor as do compatibility (what if you need to use two in the same page) and last but not least your dev teams have to be fluent in more than one API.

There has to be a better way. I personally feel that out of the box one library should be chosen, and there should be great home-grown widgets. Let’s be opinionated but have something top quality out of the box.

I mean, Grails enthusiasts like me will happily point out how Rails is not on par in terms of available libraries and enterprise infrastructure stuff, and gloat at the apparent inability to create apps that don’t leak memory and hence need many restarts – but you have to admit that a great deal of Rails sites have good widgets, and good clear designs. I believe most of these are home-spun from Prototype+Scriptaculous and cunning use of CSS.

Our Javaland/Grailsland equivalents tend to reuse the standard square tables and buttons and tiny fonts so familiar to Windows users, but anathema to people who have made the switch to Mac.

This is unfortunately what you get when people are knocking together joyless enterprise Java apps and the key thing is to get something work NOW – rather than create something that is a pleasure to use. The latter is something that the smarter businesses in the Rails crowd know all about (see the excellent Harvest, Co-op, Beanstalk or Radiant), and from which all developers, Java enterprise or otherwise, can learn. Its not OK to scrimp on the UI. Who cares if your manager doesn’t get it. Take pride in UI!

Call me a snob but universally silver, sharp-edged and small fonted UIs are aesthetically offensive to me!

iPhone – how they forgot the importance of SMS

Marc Palmer — Tue, 14 Oct 2008 09:54:58 +0000

I love the iPhone. However there are some shocking failings that persist even after several software revisions. They have particularly managed to completely miss out very basic features of SMS (texting) that every phone under the sun has. I don’t care about MMS and picture message crap – its the basics that matter.

Notable omissions include:

You cannot forward an SMS you have received to another person
You cannot send a number/vCARD from your address book to somebody else via SMS. Even my 9 year old Nokia 6100 did that.
You cannot send an SMS to a group in your Contacts book, without adding each person from the group manually. They added group SMS in an early firmware revision, but didn’t add a way to select just the group and have all members added. Sending a message to 20 people in a group is very boring.
When choosing the “Text Message” option in address book it does not automatically select their mobile number
SMS is treated as a separate feature from Phone where dialing, contacts, voicemail are. This is a bizarre and false separation. Contacts appear in the main home screen and in Phone – SMS should be the same.
There is no “mark all read” option on the main SMS summary screen – so even for short messages you’ve already read in the preview/alert screen, you have to go and view each manually.

This functionality is so basic and fundamentally affects the usefulness of SMS on iPhone.

Come on Steve, give us SMS we can be proud of!