The wonder of Grails URL Mappings

The URL mappings feature added to Grails way back in 0.5 I think, is seriously good. I hadn’t really had cause to use the constraints on mappings until the other day, and it was fantastically easy.

The problem was that I have a ContentController to handle all "normal" content pages that are GSPs. This is mapped to handle "/$id?" and "/$dir/$id?" so that the content controller can handle gsps in folders ("dir") under grails-app/views/content/

Anyway two problems cropped up. I wanted to keep the default scaffold styling for some simple admin back end – and this means URLs for /js/xxx, /css/xxx and /images/xxx have to work even though we don’t use those because we serve them statically with my Static Resources Plugin.

The other problem was that I managed to get the FCK Editor plugin installed by manually unzipping it to get past the bug that stops install-plugin completing – but some functions like Upload were throwing up errors about missing resources at /fckeditor/xxx. I put two and two together and realised these are one and the same problem.

Now I’m not aware of a way to set a URL mapping to NOT map to a controller and instead use the normal servlet dispatch stuff. However using constraints, more precisely the custom "validator" constraint, you can easily have a URL mapping rule NOT occur:

"/$dir/$id?"{   controller = "content"   action = "view"   constraints {    dir(validator: { !['css', 'images', 'js', 'blog-uploads', 'fckeditor'].contains(it) }) }

This basically lists all the folders we don’t want to handle in "dir" and if the constraint is not valid, grails lets normal processing kick in as there are no other matching URL rules for those folders.

Updated smart fields taglib for Grails

I’ve uploaded the latest version of ModelTagLib that we are deploying with Grails 1.0.2 apps. I’m either stupid, misunderstood genius or architect of overcomplicated solutions because I don’t see many people talking about this taglib and yet I don’t know how you can get by without it.

In a nutshell, it gives you data-aware form field tags. It pays attention to constraints, populates with current values, generates <label> tags for you, automatically renders field-specific errors next to fields, indicates which fields are required… all using the data you already provide in your bean constraints.

I can’t bear to manually code <g:textField> etc so every project we use is using ModelTagLib, and its been in use for over a year now. I added a sweet little feature to it recently. When rendering a field based on constraints of a domain class or command object, you have a problem if you don’t know which controller will be rendering your GSP.

Say you have a reusable panel fragment that your web monkeys can stick into any page. You don’t want to make every controller in your app, or a filter, create a dummy instance of this bean – for example a LoginForm bean. It might be just about sane for one bean, but what if there are many that might crop up in the site?

Enter the <g:requireBean/> tag. You pass it a beanName that you want to exist in the model and a className you want it to instantiate if there is no bean in the model. Bingo – if its not there it creates it and adds to the model – so <g:modelXXXX/> tags can get to the constraints.