Template tags in the play! framework are a simple, powerful way to share functionality between different pages. They have all the groovy goodness of regular templates, and you can pass variables into them easily.

But, as always, there’s always a but…

The functionality of the tags is determined by their implicit content and any parameters passed into them. Adding further configuration allows tags to have much more use as shared functions, but doing this is not obvious from the documentation.

As you can probably guess from the title, doing this is quick and easy.

The key comes from the play/groovy binding mechanism that allows variables to by dynamically declared.

Take the example of a vanilla tag which has a single argument, in a file called hello.html:

hello ${_name}

Note the use of the play convention that states variables passed into a tag are prefixed with an underscore.

This tag is invoked in the regular way:

{#hello name:'steve' /}

All well and good, but what if we want some default behaviour that can be over-ridden? For example, you may want the tag “hello” in its normal usage, but in 40% of the usages, to say “Good day” because someone in senior management can access the function and it’s felt that “hello” is far too informal. Stranger things have happened.

In this case we can rewrite the tag as:

%{ message = _formal == null ? 'Hello' : (formal ? 'Good day' : 'Hello') }%
${message} ${_name}

_formal will be null if not declared in the calling tag, and so the message will be “Hello”. If it is declared, and it’s a boolean, the message will vary according to the value.

So, the existing tag call of

{#hello name:'steve' /}

will produce

Hello Steve

but

{#hello name:'steve' formal:true/}

will produce

Good day Steve

It should be noted there is another possibility in the example above – giving a value to “formal” which is not a boolean but nonetheless a not-null object will result in “Good day”. Take this into account when setting up your defaults, and rewrite the assignment of “message” if necessary to allow for this!

Another day, another post about play!…

When you extend from play.mvc.Controller, you have access to various render methods. One of these is renderBinary(), which allows you to send binary data (captchas, images, etc) to the browser.

renderBinary() is overloaded, and one of the signatures takes an java.io.InputStream as the source of the binary data. This makes it easy to load, for example, a file from the server into the InputStream and deliver it to the browser. However, what about files that don’t exist anywhere?

More than a few places allow you to tailor what you’re downloading so you only get exactly what you need – JQuery UI springs to mind here. However, when I tried to download JQuery UI for a new project a few weeks ago, I received an error message – /tmp/foo.zip could not be written to the file system, or something similar.

Because renderBinary() renders – surprise – binary, what you’re doing is passing a bytestream into the response. Java provides a java.io.ByteArrayInputStream, which can hold all your bytes (within reasonable memory constraints) and so there is the possibility of creating in-memory files and rendering them.

In this example, I’ll take some files from the server, zip them up in memory and dump them into the response.

public class Foo extends Controller 
{
    public static void getZipFile()
    {
        ZipOutputStream zos = null;
        ByteArrayOutputStream bytes = new ByteArrayOutputStream();
        FileInputStream fileInput = null;

        try 
        {
            zipOutput = new  ZipOutputStream(new BufferedOutputStream(bytes));
            String fileNames = { "/tmp/foo.txt", "/tmp/bar.txt" };
            for (String fileName : fileNames)
            {
                ZipEntry entry = new ZipEntry(fileName);
                zipOutput.putNextEntry(entry);

                fileInput = new FileInputStream(fileName);
                byte[] buf = new byte[1024]; 
                int len; while ((len = fileInput.read(buf)) > 0) 
                {
                    zipOutput.write(buf, 0, len);
                }

                zos.closeEntry();
                // IOUtils.close() just closes the stream if it's not null, and swallows 
                // any exceptions - this is just an example!
                IOUtils.close(fileInput);
            }
            // close the output stream, but crucially this has no effect on the content 
            // of bytes (check the ByteArrayOutputStream javadoc for why)
            zipOutput.close();
            
            // at this point, bytes contains the zip "file"
            InputStream zipInput = new ByteArrayInputStream(bytes.toByteArray());
            // give the resulting binary a name in the response
            renderBinary(zipInput, "foobar.zip");
        }
        catch (IOException e)
        {
            // whatever
        }
        finally
        {
            IOUtils.close(fileInput);
            IOUtils.close(zipOutput);
        }
    }
}

There are, of course, pros and cons with any approach…

• Pros
  • You don’t write to the file system, so you don’t need to clean up the file system
  • Should be faster, due to not writing to the file system
• Cons
  • More memory intensive – potentially much more memory intensive, depending on your user requirements and what you’re actually assembling in memory
  • As written, there’s nothing on the file system for you to check for correctness (easily corrected, in a dev environment)