The beauty of Taglibs

At enotions, we have a team of designers, developers and project managers to get a project from initial concept, through design, programming and front end build and ultimately out to the client – hopefully on time and on budget; this has evolved over the years and is now working rather nicely. On the flip side, any projects I work on for personal enjoyment and edification don’t get the benefit of said team and so personal projects often have to be built with little documentation and in such a way that they "do work, but could do with refinement" – I like to think of it as a form of Agile Programming but without anyone else backing me up or checking up on me (and certainly no Scrum Master to be seen!).

Generally, my ideas start out as an A4 sheet of scrawls, crude flow charts and possibly database table relationships along with a few functionality notes, but no more. No scope or spec (after all, I don’t have anyone else working with me that I need to communicate ideas with!), just me, my untidy notebook and my iMac. When it comes to actually writing the code, I approach this in an agile manner too, Grails makes this very quick and easy indeed, simply write your classes and scaffold your controllers/views to get something working in under 10 minutes! After a very short period of time you can have a nice prototype of your application ready to show but you will soon begin to realise that, actually, there are far cleaner and more efficient ways of re-using code blocks for often-used items. For this example, we’ll assume that we’re building a DVD library: Wouldn’t it be great if HTML gave us a tag for displaying a link to Amazon with the dvd cover? Well that’s where custom taglibs come in! In an old-skool scripting language we’d probably have something like:

  1. <?php $dvd=new DVD("the-commitments"); ?>
  2. <a href="<?= $dvd->createAmazonLink();?>" title="<?= $dvd->title;?>;">
  3. <img width="35" src="/images/dvds/<?=$dvd->slug;?>.jpg" alt="<?=$dvd->title;/>" />
  4. </a>

Which would produce something along the lines of:

  1. <a title="The Commitments" href="http://www.amazon.co.uk/dvd/ASIN/xxxxxxxxxxxx/the-commitments">
  2. <img width="35" alt="The Commitments" src="/images/dvds/the-commitments.jpg" />
  3. </a>

Whereas with a taglib in grails you could use something like:

  1. <g:amazonLink product="${dvd}"><g:coverimage width="35" product="${dvd}"/></g:amazonLink>

Which would produce exactly the same output.

The clever bits are done within the taglib itself – keeping the HTML file (or .gsp file to be precise) clean, tidy and free of logic (holding true to the MVC architectural pattern). In part two I’ll give you the code within the taglib that does the actual rendering, but for now I want to compare this to PHP – because I know out there will be some people that say the things that I did at first – such as "But you could do something similar with PHP!"

One of the big selling points of grails, in my opinion, is that you’re all-but forced into using "serious" paradigms and methodologies when developing your applications. The reason for this is quite simple – they not only work, but they increase security, stability and scalability (to name but a few S words) but they manage to do so without harming productivity; in fact, a lot of the time-proven patterns used whilst developing grails applications actually increase productivity. "Convention over Configuration" is the main paradigm I’m referring to here, and this fits nicely with taglibs.

You see, it is possible to write functions in PHP to mimic this behaviour but in order to use it, you need to include the code in every page… another line of code… in a grails app, any files ending in TagLib.groovy within the taglib folder are automagically compiled into the application giving their functionality to the rest of the application without needing to specify which libraries and/or classes are required for each page.

For example our taglib for the above could be at /grails-app/taglib/DVDLibraryTagLib.groovy including the methods amazonLink() and coverImage(); these methods will be loaded when the app starts up, exposing their methods to any view (page/template) across the application.

Using this taglib we can now replace a lot of repeat code throughout our application – thus conforming closer to the DRY principal and yet another agile development pattern. When developing applications from scratch, I will tend to build the prototype using similar methods to that which I’ve used for the past eight years of PHP development (that is using a lot of raw code within loops and conditionals) until I’m happy with how it works and looks – once I’m happy with it, I’ll then move that code out into taglibs, or even back into the controllers.

This does sound like extra work, but it means I can quickly and easily refine my code before stashing it away in a taglib, not to be fiddled with again. Of course, once the code is into the taglib, I can just drop in the tag every time I want to render the same code. It often happens that I find more and more uses for the same code, so compiling a taglib to cover these re-usable methods isn’t just sensible, it has become second nature.

Having separate taglibs for different areas of your application also helps to keep your code organised and maintenance simple. We shall talk about namespaces for taglibs later but for example, we could have separate taglibs for image functions and for link functions:

  1. <sebLink:amazonLink product="${dvd}"><sebImage:coverImage product="${dvd}" width="35" />&lt/sebImage:coverImage>

See part two "Planning your first Taglib" (coming soon!) for an example taglib and how to implement it throughout your application.

One thought on “The beauty of Taglibs

Leave a Reply

Your email address will not be published. Required fields are marked *