Optimising your Application with Grails Resources Plugin

Optimising your Application with Grails Resources Plugin

Posted by: on Sep 12, 2011 | 31 Comments

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 future of computing UIs – TV and touch tablets and OS X

Posted by: on Sep 16, 2009 | No Comments

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

Posted by: on Jan 19, 2009 | 5 Comments

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 <head> 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 <head> section via <link> 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:

<esp:resource group="somepage" type="css"/>

This tag is used in the <head> 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:

<html>
<head>
  <esp:resource group="common" type="css"/>
  <esp:resource group="common" type="js"/>
  <esp:resource group="contactForm" type="js"/>
</head>
...
</html>

This tag simple outputs a <link> 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 <head> (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

or

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.

or

iii) use a <esp:done/> 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 <g:render>. All it needs is an extra <esp:get> 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 (!)

Posted by: on Jan 14, 2009 | 48 Comments

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

Posted by: on Jan 6, 2009 | 7 Comments

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!