See the light - agile, industrial strength, rapid web application development made easy

(Quick Reference) # 7.2 Groovy Server Pages - Reference Documentation Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith, Lari Hotari Version: 2.3.8 ## Table of Contents ## 7.2 Groovy Server Pages Groovy Servers Pages (or GSP for short) is Grails' view technology. It is designed to be familiar for users of technologies such as ASP and JSP, but to be far more flexible and intuitive. GSPs live in the `grails-app/views` directory and are typically rendered automatically (by convention) or with the render method such as:
    render(view: "index")
A GSP is typically a mix of mark-up and GSP tags which aid in view rendering. Although it is possible to have Groovy logic embedded in your GSP and doing this will be covered in this document, the practice is strongly discouraged. Mixing mark-up and code is a bad thing and most GSP pages contain no code and needn't do so. A GSP typically has a "model" which is a set of variables that are used for view rendering. The model is passed to the GSP view from a controller. For example consider the following controller action:
    def show() {
        [book: Book.get(params.id)]
    }
This action will look up a `Book` instance and create a model that contains a key called `book`. This key can then be referenced within the GSP view using the name `book`:
    ${book.title}
Embedding data received from user input has the risk of making your application vulnerable to an Cross Site Scripting (XSS) attack. Please read the documentation on XSS prevention for information on how to prevent XSS attacks. ## 7.2.1 GSP Basics In the next view sections we'll go through the basics of GSP and what is available to you. First off let's cover some basic syntax that users of JSP and ASP should be familiar with. GSP supports the usage of `<% %>` scriptlet blocks to embed Groovy code (again this is discouraged):
    <html>
       <body>
         <% out << "Hello GSP!" %>
       </body>
    </html>
You can also use the `<%= %>` syntax to output values:
    <html>
       <body>
         <%="Hello GSP!" %>
       </body>
    </html>
GSP also supports JSP-style server-side comments (which are not rendered in the HTML response) as the following example demonstrates:
    <html>
       <body>
         <%-- This is my comment --%>
         <%="Hello GSP!" %>
       </body>
    </html>
Embedding data received from user input has the risk of making your application vulnerable to an Cross Site Scripting (XSS) attack. Please read the documentation on XSS prevention for information on how to prevent XSS attacks. ## 7.2.1.1 Variables and Scopes Within the `<% %>` brackets you can declare variables:
    <% now = new Date() %>
and then access those variables later in the page:
    <%=now%>
Within the scope of a GSP there are a number of pre-defined variables, including: `application` - The javax.servlet.ServletContext instance `applicationContext` The Spring ApplicationContext instance `flash` - The flash object `grailsApplication` - The GrailsApplication instance `out` - The response writer for writing to the output stream `params` - The params object for retrieving request parameters `request` - The HttpServletRequest instance `response` - The HttpServletResponse instance `session` - The HttpSession instance `webRequest` - The GrailsWebRequest instance ## 7.2.1.2 Logic and Iteration Using the `<% %>` syntax you can embed loops and so on using this syntax:
    <html>
       <body>
          <% [1,2,3,4].each { num -> %>
             <p><%="Hello ${num}!" %></p>
          <%}%>
       </body>
    </html>
As well as logical branching:
    <html>
       <body>
          <% if (params.hello == 'true')%>
          <%="Hello!"%>
          <% else %>
          <%="Goodbye!"%>
       </body>
    </html>
## 7.2.1.3 Page Directives GSP also supports a few JSP-style page directives. The import directive lets you import classes into the page. However, it is rarely needed due to Groovy's default imports and GSP Tags:
    <%@ page import="java.awt.*" %>
GSP also supports the contentType directive:
    <%@ page contentType="application/json" %>
The contentType directive allows using GSP to render other formats. ## 7.2.1.4 Expressions In GSP the `<%= %>` syntax introduced earlier is rarely used due to the support for GSP expressions. A GSP expression is similar to a JSP EL expression or a Groovy GString and takes the form `${expr}`:
    <html>
      <body>
        Hello ${params.name}
      </body>
    </html>
However, unlike JSP EL you can have any Groovy expression within the `${..}` block. Embedding data received from user input has the risk of making your application vulnerable to an Cross Site Scripting (XSS) attack. Please read the documentation on XSS prevention for information on how to prevent XSS attacks. ## 7.2.2 GSP Tags Now that the less attractive JSP heritage has been set aside, the following sections cover GSP's built-in tags, which are the preferred way to define GSP pages. The section on Tag Libraries covers how to add your own custom tag libraries. All built-in GSP tags start with the prefix `g:`. Unlike JSP, you don't specify any tag library imports. If a tag starts with `g:` it is automatically assumed to be a GSP tag. An example GSP tag would look like:
    <g:example />
GSP tags can also have a body such as:
    <g:example>
       Hello world
    </g:example>
Expressions can be passed into GSP tag attributes, if an expression is not used it will be assumed to be a String value:
    <g:example attr="${new Date()}">
       Hello world
    </g:example>
Maps can also be passed into GSP tag attributes, which are often used for a named parameter style syntax:
    <g:example attr="${new Date()}" attr2="[one:1, two:2, three:3]">
       Hello world
    </g:example>
Note that within the values of attributes you must use single quotes for Strings:
    <g:example attr="${new Date()}" attr2="[one:'one', two:'two']">
       Hello world
    </g:example>
With the basic syntax out the way, the next sections look at the tags that are built into Grails by default. ## 7.2.2.1 Variables and Scopes Variables can be defined within a GSP using the set tag:
    <g:set var="now" value="${new Date()}" />
Here we assign a variable called `now` to the result of a GSP expression (which simply constructs a new `java.util.Date` instance). You can also use the body of the `<g:set>` tag to define a variable:
    <g:set var="myHTML">
       Some re-usable code on: ${new Date()}
    </g:set>
The assigned value can also be a bean from the applicationContext:
    <g:set var="bookService" bean="bookService" />
Variables can also be placed in one of the following scopes: `page` - Scoped to the current page (default) `request` - Scoped to the current request `flash` - Placed within flash scope and hence available for the next request `session` - Scoped for the user session `application` - Application-wide scope. To specify the scope, use the `scope` attribute:
    <g:set var="now" value="${new Date()}" scope="request" />
## 7.2.2.2 Logic and Iteration GSP also supports logical and iterative tags out of the box. For logic there are if, else and elseif tags for use with branching:
    <g:if test="${session.role == 'admin'}">
       <%-- show administrative functions --%>
    </g:if>
    <g:else>
       <%-- show basic functions --%>
    </g:else>
Use the each and while tags for iteration:

    <g:each in="${[1,2,3]}" var="num">
       <p>Number ${num}</p>
    </g:each><g:set var="num" value="${1}" />
    <g:while test="${num < 5 }">
        <p>Number ${num++}</p>
    </g:while>
## 7.2.2.3 Search and Filtering If you have collections of objects you often need to sort and filter them. Use the findAll and grep tags for these tasks:
    Stephen King's Books:
    <g:findAll in="${books}" expr="it.author == 'Stephen King'">
         <p>Title: ${it.title}</p>
    </g:findAll>
The `expr` attribute contains a Groovy expression that can be used as a filter. The grep tag does a similar job, for example filtering by class:
    <g:grep in="${books}" filter="NonFictionBooks.class">
         <p>Title: ${it.title}</p>
    </g:grep>
Or using a regular expression:
    <g:grep in="${books.title}" filter="~/.*?Groovy.*?/">
         <p>Title: ${it}</p>
    </g:grep>
The above example is also interesting due to its usage of GPath. GPath is an XPath-like language in Groovy. The `books` variable is a collection of `Book` instances. Since each `Book` has a `title`, you can obtain a list of Book titles using the expression `books.title`. Groovy will auto-magically iterate the collection, obtain each title, and return a new list! ## 7.2.2.4 Links and Resources GSP also features tags to help you manage linking to controllers and actions. The link tag lets you specify controller and action name pairing and it will automatically work out the link based on the URL Mappings, even if you change them! For example:

    <g:link action="show" id="1">Book 1</g:link><g:link action="show" id="${currentBook.id}">${currentBook.name}</g:link><g:link controller="book">Book Home</g:link><g:link controller="book" action="list">Book List</g:link><g:link url="[action: 'list', controller: 'book']">Book List</g:link><g:link params="[sort: 'title', order: 'asc', author: currentBook.author]"
            action="list">Book List</g:link>
## 7.2.2.5 Forms and Fields #### Form Basics GSP supports many different tags for working with HTML forms and fields, the most basic of which is the form tag. This is a controller/action aware version of the regular HTML form tag. The `url` attribute lets you specify which controller and action to map to:
    <g:form name="myForm" url="[controller:'book',action:'list']">...</g:form>
In this case we create a form called `myForm` that submits to the `BookController`'s `list` action. Beyond that all of the usual HTML attributes apply. #### Form Fields In addition to easy construction of forms, GSP supports custom tags for dealing with different types of fields, including: textField - For input fields of type 'text' passwordField - For input fields of type 'password' checkBox - For input fields of type 'checkbox' radio - For input fields of type 'radio' hiddenField - For input fields of type 'hidden' select - For dealing with HTML select boxes Each of these allows GSP expressions for the value:
    <g:textField name="myField" value="${myValue}" />
GSP also contains extended helper versions of the above tags such as radioGroup (for creating groups of radio tags), localeSelect, currencySelect and timeZoneSelect (for selecting locales, currencies and time zones respectively). #### Multiple Submit Buttons The age old problem of dealing with multiple submit buttons is also handled elegantly with Grails using the actionSubmit tag. It is just like a regular submit, but lets you specify an alternative action to submit to:
    <g:actionSubmit value="Some update label" action="update" />
## 7.2.2.6 Tags as Method Calls One major different between GSP tags and other tagging technologies is that GSP tags can be called as either regular tags or as method calls from controllers, tag libraries or GSP views. #### Tags as method calls from GSPs Tags return their results as a String-like object (a `StreamCharBuffer` which has all of the same methods as String) instead of writing directly to the response when called as methods. For example:
    Static Resource: ${createLinkTo(dir: "images", file: "logo.jpg")}
This is particularly useful for using a tag within an attribute:
    <img src="${createLinkTo(dir: 'images', file: 'logo.jpg')}" />
In view technologies that don't support this feature you have to nest tags within tags, which becomes messy quickly and often has an adverse effect of WYSWIG tools such as Dreamweaver that attempt to render the mark-up as it is not well-formed:
    <img src="<g:createLinkTo dir="images" file="logo.jpg" />" />
#### Tags as method calls from Controllers and Tag Libraries You can also invoke tags from controllers and tag libraries. Tags within the default `g:` namespace can be invoked without the prefix and a `StreamCharBuffer` result is returned:
    def imageLocation = createLinkTo(dir:"images", file:"logo.jpg").toString()
Prefix the namespace to avoid naming conflicts:
    def imageLocation = g.createLinkTo(dir:"images", file:"logo.jpg").toString()
For tags that use a custom namespace, use that prefix for the method call. For example (from the FCK Editor plugin):
    def editor = fckeditor.editor(name: "text", width: "100%", height: "400")
## 7.2.3 Views and Templates Grails also has the concept of templates. These are useful for partitioning your views into maintainable chunks, and combined with Layouts provide a highly re-usable mechanism for structured views. #### Template Basics Grails uses the convention of placing an underscore before the name of a view to identify it as a template. For example, you might have a template that renders Books located at `grails-app/views/book/_bookTemplate.gsp`:
    <div class="book" id="${book?.id}">
       <div>Title: ${book?.title}</div>
       <div>Author: ${book?.author?.name}</div>
    </div>
Use the render tag to render this template from one of the views in `grails-app/views/book`:
    <g:render template="bookTemplate" model="[book: myBook]" />
Notice how we pass into a model to use using the `model` attribute of the `render` tag. If you have multiple `Book` instances you can also render the template for each `Book` using the render tag with a `collection` attribute:
    <g:render template="bookTemplate" var="book" collection="${bookList}" />
#### Shared Templates In the previous example we had a template that was specific to the `BookController` and its views at `grails-app/views/book`. However, you may want to share templates across your application. In this case you can place them in the root views directory at grails-app/views or any subdirectory below that location, and then with the template attribute use an absolute location starting with `/` instead of a relative location. For example if you had a template called `grails-app/views/shared/_mySharedTemplate.gsp`, you would reference it as:
    <g:render template="/shared/mySharedTemplate" />
You can also use this technique to reference templates in any directory from any view or controller:
    <g:render template="/book/bookTemplate" model="[book: myBook]" />
#### The Template Namespace Since templates are used so frequently there is template namespace, called `tmpl`, available that makes using templates easier. Consider for example the following usage pattern:
    <g:render template="bookTemplate" model="[book:myBook]" />
This can be expressed with the `tmpl` namespace as follows:
    <tmpl:bookTemplate book="${myBook}" />
#### Templates in Controllers and Tag Libraries You can also render templates from controllers using the render controller method. This is useful for Ajax applications where you generate small HTML or data responses to partially update the current page instead of performing new request:
    def bookData() {
        def b = Book.get(params.id)
        render(template:"bookTemplate", model:[book:b])
    }
The render controller method writes directly to the response, which is the most common behaviour. To instead obtain the result of template as a String you can use the render tag:
    def bookData() {
        def b = Book.get(params.id)
        String content = g.render(template:"bookTemplate", model:[book:b])
        render content
    }
Notice the usage of the `g` namespace which tells Grails we want to use the tag as method call instead of the render method. ## 7.2.4 Layouts with Sitemesh #### Creating Layouts Grails leverages Sitemesh, a decorator engine, to support view layouts. Layouts are located in the `grails-app/views/layouts` directory. A typical layout can be seen below:
    <html>
        <head>
            <title><g:layoutTitle default="An example decorator" /></title>
            <g:layoutHead />
        </head>
        <body onload="${pageProperty(name:'body.onload')}">
            <div class="menu"><!--my common menu goes here--></menu>
                <div class="body">
                    <g:layoutBody />
                </div>
            </div>
        </body>
    </html>
The key elements are the layoutHead, layoutTitle and layoutBody tag invocations: `layoutTitle` - outputs the target page's title `layoutHead` - outputs the target page's head tag contents `layoutBody` - outputs the target page's body tag contents The previous example also demonstrates the pageProperty tag which can be used to inspect and return aspects of the target page. #### Triggering Layouts There are a few ways to trigger a layout. The simplest is to add a meta tag to the view:
    <html>
        <head>
            <title>An Example Page</title>
            <meta name="layout" content="main" />
        </head>
        <body>This is my content!</body>
    </html>
In this case a layout called `grails-app/views/layouts/main.gsp` will be used to layout the page. If we were to use the layout from the previous section the output would resemble this:
    <html>
        <head>
            <title>An Example Page</title>
        </head>
        <body onload="">
            <div class="menu"><!--my common menu goes here--></div>
            <div class="body">
                This is my content!
            </div>
        </body>
    </html>
#### Specifying A Layout In A Controller Another way to specify a layout is to specify the name of the layout by assigning a value to the "layout" property in a controller. For example, if you have a controller such as:

    class BookController {
        static layout = 'customer'    def list() { … }
    }
You can create a layout called `grails-app/views/layouts/customer.gsp` which will be applied to all views that the `BookController` delegates to. The value of the "layout" property may contain a directory structure relative to the `grails-app/views/layouts/` directory. For example:

    class BookController {
        static layout = 'custom/customer'    def list() { … }
    }
Views rendered from that controller would be decorated with the `grails-app/views/layouts/custom/customer.gsp` template. #### Layout by Convention Another way to associate layouts is to use "layout by convention". For example, if you have this controller:
    class BookController {
        def list() { … }
    }
You can create a layout called `grails-app/views/layouts/book.gsp`, which will be applied to all views that the `BookController` delegates to. Alternatively, you can create a layout called `grails-app/views/layouts/book/list.gsp` which will only be applied to the `list` action within the `BookController`. If you have both the above mentioned layouts in place the layout specific to the action will take precedence when the list action is executed. If a layout may not be located using any of those conventions, the convention of last resort is to look for the application default layout which is `grails-app/views/layouts/application.gsp`. The name of the application default layout may be changed by defining a property in `grails-app/conf/Config.groovy` as follows:
    grails.sitemesh.default.layout = 'myLayoutName'
With that property in place, the application default layout will be `grails-app/views/layouts/myLayoutName.gsp`. #### Inline Layouts Grails' also supports Sitemesh's concept of inline layouts with the applyLayout tag. This can be used to apply a layout to a template, URL or arbitrary section of content. This lets you even further modularize your view structure by "decorating" your template includes. Some examples of usage can be seen below:

    <g:applyLayout name="myLayout" template="bookTemplate" collection="${books}" /><g:applyLayout name="myLayout" url="http://www.google.com" /><g:applyLayout name="myLayout">
    The content to apply a layout to
    </g:applyLayout>
#### Server-Side Includes While the applyLayout tag is useful for applying layouts to external content, if you simply want to include external content in the current page you use the include tag:
    <g:include controller="book" action="list" />
You can even combine the include tag and the applyLayout tag for added flexibility:
    <g:applyLayout name="myLayout">
       <g:include controller="book" action="list" />
    </g:applyLayout>
Finally, you can also call the include tag from a controller or tag library as a method:
    def content = include(controller:"book", action:"list")
The resulting content will be provided via the return value of the include tag. ## 7.2.5 Static Resources Grails 2.0 integrates with the Resources plugin to provide sophisticated static resource management. This plugin is installed by default in new Grails applications. The basic way to include a link to a static resource in your application is to use the resource tag. This simple approach creates a URI pointing to the file. However modern applications with dependencies on multiple JavaScript and CSS libraries and frameworks (as well as dependencies on multiple Grails plugins) require something more powerful. The issues that the Resources framework tackles are: Web application performance tuning is difficult Correct ordering of resources, and deferred inclusion of JavaScript Resources that depend on others that must be loaded first The need for a standard way to expose static resources in plugins and applications The need for an extensible processing chain to optimize resources Preventing multiple inclusion of the same resource The plugin achieves this by introducing new artefacts and processing the resources using the server's local file system. It adds artefacts for declaring resources, for declaring "mappers" that can process resources, and a servlet filter to serve processed resources. What you get is an incredibly advanced resource system that enables you to easily create highly optimized web applications that run the same in development and in production. The Resources plugin documentation provides a more detailed overview of the concepts which will be beneficial when reading the following guide. ## 7.2.5.1 Including resources using the resource tags #### Pulling in resources with r:require To use resources, your GSP page must indicate which resource modules it requires. For example with the jQuery plugin, which exposes a "jquery" resource module, to use jQuery in any page on your site you simply add:
    <html>
       <head>
          <r:require module="jquery"/>
          <r:layoutResources/>
       </head>
       <body>
          …
          <r:layoutResources/>
       </body>
    </html>
This will automatically include all resources needed for jQuery, including them at the correct locations in the page. By default the plugin sets the disposition to be "head", so they load early in the page. You can call `r:require` multiple times in a GSP page, and you use the "modules" attribute to provide a list of modules:
    <html>
       <head>
          <r:require modules="jquery, main, blueprint, charting"/>
          <r:layoutResources/>
       </head>
       <body>
          …
          <r:layoutResources/>
       </body>
    </html>
The above may result in many JavaScript and CSS files being included, in the correct order, with some JavaScript files loading at the end of the body to improve the apparent page load time. However you cannot use r:require in isolation - as per the examples you must have the <r:layoutResources/> tag to actually perform the render. #### Rendering the links to resources with r:layoutResources When you have declared the resource modules that your GSP page requires, the framework needs to render the links to those resources at the correct time. To achieve this correctly, you must include the r:layoutResources tag twice in your page, or more commonly, in your GSP layout:
    <html>
       <head>
          <g:layoutTitle/>
          <r:layoutResources/>
       </head>
       <body>
          <g:layoutBody/>
          <r:layoutResources/>
       </body>
    </html>
This represents the simplest Sitemesh layout you can have that supports Resources. The Resources framework has the concept of a "disposition" for every resource. This is an indication of where in the page the resource should be included. The default disposition applied depends on the type of resource. All CSS must be rendered in <head> in HTML, so "head" is the default for all CSS, and will be rendered by the first r:layoutResources. Page load times are improved when JavaScript is loaded after the page content, so the default for JavaScript files is "defer", which means it is rendered when the second r:layoutResources is invoked. Note that both your GSP page and your Sitemesh layout (as well as any GSP template fragments) can call r:require to depend on resources. The only limitation is that you must call r:require before the r:layoutResources that should render it. #### Adding page-specific JavaScript code with r:script Grails has the javascript tag which is adapted to defer to Resources plugin if installed, but it is recommended that you call `r:script` directly when you need to include fragments of JavaScript code. This lets you write some "inline" JavaScript which is actually not rendered inline, but either in the <head> or at the end of the body, based on the disposition. Given a Sitemesh layout like this:
    <html>
       <head>
          <g:layoutTitle/>
          <r:layoutResources/>
       </head>
       <body>
          <g:layoutBody/>
          <r:layoutResources/>
       </body>
    </html>
...in your GSP you can inject some JavaScript code into the head or deferred regions of the page like this:
    <html>
       <head>
          <title>Testing r:script magic!</title>
       </head>
       <body>
          <r:script disposition="head">
             window.alert('This is at the end of <head>');
          </r:script>
          <r:script disposition="defer">
             window.alert('This is at the end of the body, and the page has loaded.');
          </r:script>
       </body>
    </html>
The default disposition is "defer", so the disposition in the latter r:script is purely included for demonstration. Note that such r:script code fragments always load after any modules that you have used, to ensure that any required libraries have loaded. #### Linking to images with r:img This tag is used to render `<img>` markup, using the Resources framework to process the resource on the fly (if configured to do so - e.g. make it eternally cacheable). This includes any extra attributes on the `<img>` tag if the resource has been previously declared in a module. With this mechanism you can specify the width, height and any other attributes in the resource declaration in the module, and they will be pulled in as necessary. Example:
    <html>
       <head>
          <title>Testing r:img</title>
       </head>
       <body>
          <r:img uri="/images/logo.png"/>
       </body>
    </html>
Note that Grails has a built-in `g:img` tag as a shortcut for rendering `<img>` tags that refer to a static resource. The Grails img tag is Resources-aware and will delegate to `r:img` if found. However it is recommended that you use `r:img` directly if using the Resources plugin. Alongside the regular Grails resource tag attributes, this also supports the "uri" attribute for increased brevity. See r:resource documentation for full details. ## 7.2.5.2 Other resource tags #### r:resource This is equivalent to the Grails resource tag, returning a link to the processed static resource. Grails' own `g:resource` tag delegates to this implementation if found, but if your code requires the Resources plugin, you should use `r:resource` directly. Alongside the regular Grails resource tag attributes, this also supports the "uri" attribute for increased brevity. See r:resource documentation for full details. #### r:external This is a resource-aware version of Grails external tag which renders the HTML markup necessary to include an external file resource such as CSS, JS or a favicon. See r:resource documentation for full details. ## 7.2.5.3 Declaring resources A DSL is provided for declaring resources and modules. This can go either in your `Config.groovy` in the case of application-specific resources, or more commonly in a resources artefact in `grails-app/conf`. Note that you do not need to declare all your static resources, especially images. However you must to establish dependencies or other resources-specific attributes. Any resource that is not declared is called "ad-hoc" and will still be processed using defaults for that resource type. Consider this example resource configuration file, `grails-app/conf/MyAppResources.groovy`:

    modules = {
        core {
            dependsOn 'jquery, utils'        resource url: '/js/core.js', disposition: 'head'
            resource url: '/js/ui.js'
            resource url: '/css/main.css',
            resource url: '/css/branding.css'
            resource url: '/css/print.css', attrs: [media: 'print']
        }    utils {
            dependsOn 'jquery'        resource url: '/js/utils.js'
        }    forms {
            dependsOn 'core,utils'        resource url: '/css/forms.css'
            resource url: '/js/forms.js'
        }
    }
This defines three resource modules; 'core', 'utils' and 'forms'. The resources in these modules will be automatically bundled out of the box according to the module name, resulting in fewer files. You can override this with `bundle:'someOtherName'` on each resource, or call `defaultBundle` on the module (see resources plugin documentation). It declares dependencies between them using `dependsOn`, which controls the load order of the resources. When you include an `<r:require module="forms"/>` in your GSP, it will pull in all the resources from 'core' and 'utils' as well as 'jquery', all in the correct order. You'll also notice the `disposition:'head'` on the `core.js` file. This tells Resources that while it can defer all the other JS files to the end of the body, this one must go into the `<head>`. The CSS file for print styling adds custom attributes using the `attrs` map option, and these are passed through to the `r:external` tag when the engine renders the link to the resource, so you can customize the HTML attributes of the generated link. There is no limit to the number of modules or xxxResources.groovy artefacts you can provide, and plugins can supply them to expose modules to applications, which is exactly how the jQuery plugin works. To define modules like this in your application's Config.groovy, you simply assign the DSL closure to the `grails.resources.modules` Config variable. For full details of the resource DSL please see the resources plugin documentation. ## 7.2.5.4 Overriding plugin resources Because a resource module can define the bundle groupings and other attributes of resources, you may find that the settings provided are not correct for your application. For example, you may wish to bundle jQuery and some other libraries all together in one file. There is a load-time and caching trade-off here, but often it is the case that you'd like to override some of these settings. To do this, the DSL supports an "overrides" clause, within which you can change the `defaultBundle` setting for a module, or attributes of individual resources that have been declared with a unique id:

    modules = {
        core {
            dependsOn 'jquery, utils'
            defaultBundle 'monolith'        resource url: '/js/core.js', disposition: 'head'
            resource url: '/js/ui.js'
            resource url: '/css/main.css',
            resource url: '/css/branding.css'
            resource url: '/css/print.css', attrs: [media: 'print']
        }    utils {
            dependsOn 'jquery'
            defaultBundle 'monolith'        resource url: '/js/utils.js'
        }    forms {
            dependsOn 'core,utils'
            defaultBundle 'monolith'        resource url: '/css/forms.css'
            resource url: '/js/forms.js'
        }    overrides {
            jquery {
                defaultBundle 'monolith'
            }
        }
    }
This will put all code into a single bundle named 'monolith'. Note that this can still result in multiple files, as separate bundles are required for head and defer dispositions, and JavaScript and CSS files are bundled separately. Note that overriding individual resources requires the original declaration to have included a unique id for the resource. For full details of the resource DSL please see the resources plugin documentation. ## 7.2.5.5 Optimizing your resources The Resources framework uses "mappers" to mutate the resources into the final format served to the user. The resource mappers are applied to each static resource once, in a specific order. You can create your own resource mappers, and several plugins provide some already for zipping, caching and minifying. Out of the box, the Resources plugin provides bundling of resources into fewer files, which is achieved with a few mappers that also perform CSS re-writing to handle when your CSS files are moved into a bundle. #### Bundling multiple resources into fewer files The 'bundle' mapper operates by default on any resource with a "bundle" defined - or inherited from a `defaultBundle` clause on the module. Modules have an implicit default bundle name the same as the name of the module. Files of the same kind will be aggregated into this bundle file. Bundles operate across module boundaries:

    modules = {
        core {
            dependsOn 'jquery, utils'
            defaultBundle 'common'        resource url: '/js/core.js', disposition: 'head'
            resource url: '/js/ui.js', bundle: 'ui'
            resource url: '/css/main.css', bundle: 'theme'
            resource url: '/css/branding.css'
            resource url: '/css/print.css', attrs: [media: 'print']
        }    utils {
            dependsOn 'jquery'        resource url: '/js/utils.js', bundle: 'common'
        }    forms {
            dependsOn 'core,utils'        resource url: '/css/forms.css', bundle: 'ui'
            resource url: '/js/forms.js', bundle: 'ui'
        }
    }
Here you see that resources are grouped into bundles; 'common', 'ui' and 'theme' - across module boundaries. Note that auto-bundling by module does not occur if there is only one resource in the module. #### Making resources cache "eternally" in the client browser Caching resources "eternally" in the client is only viable if the resource has a unique name that changes whenever the contents change, and requires caching headers to be set on the response. The cached-resources plugin provides a mapper that achieves this by hashing your files and renaming them based on this hash. It also sets the caching headers on every response for those resources. To use, simply install the cached-resources plugin. Note that the caching headers can only be set if your resources are being served by your application. If you have another server serving the static content from your app (e.g. Apache HTTPD), configure it to send caching headers. Alternatively you can configure it to request and proxy the resources from your container. #### Zipping resources Returning gzipped resources is another way to reduce page load times and reduce bandwidth. The zipped-resources plugin provides a mapper that automatically compresses your content, excluding by default already compressed formats such as gif, jpeg and png. Simply install the zipped-resources plugin and it works. #### Minifying There are a number of CSS and JavaScript minifiers available to obfuscate and reduce the size of your code. At the time of writing none are publicly released but releases are imminent. ## 7.2.5.6 Debugging When your resources are being moved around, renamed and otherwise mutated, it can be hard to debug client-side issues. Modern browsers, especially Safari, Chrome and Firefox have excellent tools that let you view all the resources requested by a page, including the headers and other information about them. There are several debugging features built in to the Resources framework. #### X-Grails-Resources-Original-Src Header Every resource served in development mode will have the X-Grails-Resources-Original-Src: header added, indicating the original source file(s) that make up the response. #### Adding the debug flag If you add a query parameter _debugResources=y to your URL and request the page, Resources will bypass any processing so that you can see your original source files. This also adds a unique timestamp to all your resource URLs, to defeat any caching that browsers may use. This means that you should always see your very latest code when you reload the page. #### Turning on debug all the time You can turn on the aforementioned debug mechanism without requiring a query parameter, but turning it on in Config.groovy:
    grails.resources.debug = true
You can of course set this per-environment. ## 7.2.5.7 Preventing processing of resources Sometimes you do not want a resource to be processed in a particular way, or even at all. Occasionally you may also want to disable all resource mapping. #### Preventing the application of a specific mapper to an individual resource All resource declarations support a convention of noXXXX:true where XXXX is a mapper name. So for example to prevent the "hashandcache" mapper from being applied to a resource (which renames and moves it, potentially breaking relative links written in JavaScript code), you would do this:
    modules = {
        forms {
            resource url: '/css/forms.css', nohashandcache: true
            resource url: '/js/forms.js', nohashandcache: true
        }
    }
#### Excluding/including paths and file types from specific mappers Mappers have includes/excludes Ant patterns to control whether they apply to a given resource. Mappers set sensible defaults for these based on their activity, for example the zipped-resources plugin's "zip" mapper is set to exclude images by default. You can configure this in your `Config.groovy` using the mapper name e.g:

    // We wouldn't link to .exe files using Resources but for the sake of example:
    grails.resources.zip.excludes = ['**/*.zip', '**/*.exe']// Perhaps for some reason we want to prevent bundling on "less" CSS files:
    grails.resources.bundle.excludes = ['**/*.less']
There is also an "includes" inverse. Note that settings these replaces the default includes/excludes for that mapper - it is not additive. #### Controlling what is treated as an "ad-hoc" (legacy) resource Ad-hoc resources are those undeclared, but linked to directly in your application without using the Grails or Resources linking tags (resource, img or external). These may occur with some legacy plugins or code with hardcoded paths in. There is a Config.groovy setting grails.resources.adhoc.patterns which defines a list of Servlet API compliant filter URI mappings, which the Resources filter will use to detect such "ad-hoc resource" requests. By default this is set to:
    grails.resources.adhoc.patterns = ['images/*', '*.js', '*.css']
## 7.2.5.8 Other Resources-aware plugins At the time of writing, the following plugins include support for the Resources framework: jquery jquery-ui blueprint lesscss-resources zipped-resources cached-resources ## 7.2.6 Sitemesh Content Blocks Although it is useful to decorate an entire page sometimes you may find the need to decorate independent sections of your site. To do this you can use content blocks. To get started, partition the page to be decorated using the `<content>` tag:

    <content tag="navbar">
    … draw the navbar here…
    </content><content tag="header">
    … draw the header here…
    </content><content tag="footer">
    … draw the footer here…
    </content><content tag="body">
    … draw the body here…
    </content>
Then within the layout you can reference these components and apply individual layouts to each:
    <html>
        <body>
            <div id="header">
                <g:applyLayout name="headerLayout">
                    <g:pageProperty name="page.header" />
                </g:applyLayout>
            </div>
            <div id="nav">
                <g:applyLayout name="navLayout">
                    <g:pageProperty name="page.navbar" />
                </g:applyLayout>
            </div>
            <div id="body">
                <g:applyLayout name="bodyLayout">
                    <g:pageProperty name="page.body" />
                </g:applyLayout>
            </div>
            <div id="footer">
                <g:applyLayout name="footerLayout">
                    <g:pageProperty name="page.footer" />
                </g:applyLayout>
            </div>
        </body>
    </html>
## 7.2.7 Making Changes to a Deployed Application One of the main issues with deploying a Grails application (or typically any servlet-based one) is that any change to the views requires that you redeploy your whole application. If all you want to do is fix a typo on a page, or change an image link, it can seem like a lot of unnecessary work. For such simple requirements, Grails does have a solution: the `grails.gsp.view.dir` configuration setting. How does this work? The first step is to decide where the GSP files should go. Let's say we want to keep them unpacked in a `/var/www/grails/my-app` directory. We add these two lines to `grails-app/conf/Config.groovy` :
    grails.gsp.enable.reload = true
    grails.gsp.view.dir = "/var/www/grails/my-app/"
The first line tells Grails that modified GSP files should be reloaded at runtime. If you don't have this setting, you can make as many changes as you like but they won't be reflected in the running application until you restart. The second line tells Grails where to load the views and layouts from. The trailing slash on the `grails.gsp.view.dir` value is important! Without it, Grails will look for views in the parent directory. Setting "grails.gsp.view.dir" is optional. If it's not specified, you can update files directly to the application server's deployed war directory. Depending on the application server, these files might get overwritten when the server is restarted. Most application servers support "exploded war deployment" which is recommended in this case. With those settings in place, all you need to do is copy the views from your web application to the external directory. On a Unix-like system, this would look something like this:
    mkdir -p /var/www/grails/my-app/grails-app/views
    cp -R grails-app/views/* /var/www/grails/my-app/grails-app/views
The key point here is that you must retain the view directory structure, including the `grails-app/views` bit. So you end up with the path `/var/www/grails/my-app/grails-app/views/...` . One thing to bear in mind with this technique is that every time you modify a GSP, it uses up permgen space. So at some point you will eventually hit "out of permgen space" errors unless you restart the server. So this technique is not recommended for frequent or large changes to the views. There are also some System properties to control GSP reloading:
Name | Description | Default
--- | --- | ---
grails.gsp.enable.reload | altervative system property for enabling the GSP reload mode without changing Config.groovy |
grails.gsp.reload.interval | interval between checking the lastmodified time of the gsp source file, unit is milliseconds | 5000
grails.gsp.reload.granularity | the number of milliseconds leeway to give before deciding a file is out of date. this is needed because different roundings usually cause a 1000ms difference in lastmodified times | 1000
GSP reloading is supported for precompiled GSPs since Grails 1.3.5 . ## 7.2.8 GSP Debugging #### Viewing the generated source code Adding "?showSource=true" or "&showSource=true" to the url shows the generated Groovy source code for the view instead of rendering it. It won't show the source code of included templates. This only works in development mode The saving of all generated source code can be activated by setting the property "grails.views.gsp.keepgenerateddir" (in Config.groovy) . It must point to a directory that exists and is writable. During "grails war" gsp pre-compilation, the generated source code is stored in grails.project.work.dir/gspcompile (usually in ~/.grails/(grails_version)/projects/(project name)/gspcompile). #### Debugging GSP code with a debugger See Debugging GSP in STS #### Viewing information about templates used to render a single url GSP templates are reused in large web applications by using the `g:render` taglib. Several small templates can be used to render a single page. It might be hard to find out what GSP template actually renders the html seen in the result. The debug templates -feature adds html comments to the output. The comments contain debug information about gsp templates used to render the page. Usage is simple: append "?debugTemplates" or "&debugTemplates" to the url and view the source of the result in your browser. "debugTemplates" is restricted to development mode. It won't work in production. Here is an example of comments added by debugTemplates :
    <!-- GSP #2 START template: /home/.../views/_carousel.gsp
         precompiled: false lastmodified: … -->
    .
    .
    .
    <!-- GSP #2 END template: /home/.../views/_carousel.gsp
         rendering time: 115 ms -->
Each comment block has a unique id so that you can find the start & end of each template call. | Quick Reference (hide)