IntelliJ IDEA 13 has a new feature Search Everywhere. With this feature we can search for files, actions, classes, settings and more using a simple search dialog box. We must press the Shift button twice to get the Search Everywhere dialog.
When we convert a List or Set to XML using the Grails XML marshalling support the name of the root element is either <list> or <set>. We can change this name by extending the org.codehaus.groovy.grails.web.converters.marshaller.xml.CollectionMarshaller. We must override the method supports() to denote the type of collection we want to customize the root element name for. And we must override the method getElementName() which returns the actual name of the root element for the List or Set.
Let's first see the default output of a collection of Book domain classes. In a controller we have the following code:
When we use for example the compile or war command Grails will create files and stores them by default in the project's working directory. The location of the project working directory can be customized in our grails-app/conf/BuildConfig.groovy configuration file. We remove the generated files with the Grails clean command. This command will remove all compiled class files, the WAR file, cached scripts and test reports. But this doesn't remove all files in the project working directory. For example plugins or a temporary web.xml file, which are stored in the project working directory are not removed. We must use the clean-all command to also remove those files from the project working directory completely.
Let's take a look at the default settings in our grails-app/conf/BuildConfig.groovy configuration file when we create a new Grails application:
Since Grails 2.2 by default the run-app command will launch the Grails application in a separate Java Virtual Machine. This is called forked Tomcat execution in Grails. This way the class path of the Grails build system and the application will not intervene and also both processes will have their own memory settings. We can see the settings in grails-app/conf/BuildConfig.groovy where we find the configuration property grails.project.fork.run. When we want to debug our application in an IDE like IntelliJ IDEA we cannot use the Debug command, because this will only allow us to debug the Grails build system. We will not reach breakpoints in our source code. But Grails 2.3 introduces an extra argument for the run-app command: --debug-fork. If we use this extra argument the JVM running the Grails application will stop and listen for a debug session to be attached and then continue. We can configure a Debug configuration in IntelliJ IDEA (or another IDE) to attach to the waiting Grails application and use breakpoints and other debugging tools like we are used to.
Suppose we have a Grails application named forked-debug and we have created a project in IDEA for this application. We click on the Select Run/Debug Configuration button and select Edit Configurations...:
To generate an HTML select we can use the Grails tag <g:select .../>. We use the optionValue attribute to specify a specific property we want to be used as the value. But we can also define a closure for the optionValue attribute to further customize the value that is shown to the user.
Suppose we have a simple domain class Book with a couple of properties. We want to combine multiple properties as the text for the HTML select options. In the following GSP we define first a <g:select .../> tag where we simply use the title property. In the next <g:select .../> tag we use a closure to combine multiple properties.
Grails 2.3 added a lot of support for RESTful services. For example we can now use a respond() method in our controllers to automatically render resources. The respond() method accepts a resource instance as argument and a map of attributes that can be passed. We can use the includes and excludes keys of the map to pass which fields of our resources need to be included or excluded in the response. This way we can render partial responses based on a request parameter value.
First we start with a simple domain class Book:
When we convert data to JSON or XML (or any other format actually) in our Grails application we can register custom marshallers. These marshallers must contain the logic to convert an input object to a given format. For example we could have a book class and we want to convert it to our own JSON format. We have different options in Grails to achieve this, but for now we will create a custom marshaller class CustomBookMarshaller. This class must implement the ObjectMarshaller<C> interface. The generic type is the converter the marshaller is for and is in most cases either grails.converters.XML or grails.converters.JSON. Next we must make sure Grails uses our custom marshaller and we must register it. In the Grails documentation is explained how to do this via grails-app/conf/Bootstrap.groovy where we invoke for example JSON.registerMarshaller(new CustomBookMarshaller()). Or via grails-app/conf/spring/resources.groovy where we must write an extra component with a method annotated @PostConstruct where JSON.registerMarshaller(new CustomBookMarshaller()) is invoked.
But there is also another way using org.codehaus.groovy.grails.web.converters.configuration.ObjectMarshallerRegisterer. This is a Spring bean just for configuring extra marshallers. The bean has a priority property we can use to define the priority for this marshaller. Grails will use a marshaller with the highest priority if for the same class multiple marshallers are defined. We can assign a marshaller to the marshaller property. And finally we must set the converter class, for example grails.converters.XML or grails.converters.JSON with the converter property.
We can include the version property of domain classes in rendered JSON or XML output. By default the version property is not included in generated XML and JSON. To enable inclusion of the version property we can set the configuration property grails.converters.domain.include.version with the value true. With this property for both XML and JSON the version property is included in the output. To only enable this for XML we use the property grails.converters.xml.domain.include.version and for JSON we use the property grails.converters.json.domain.include.version.
The following snippet is from grails-app/conf/Config.groovy where the properties are defined:
If our Grails application renders XML or JSON output we can set configuration properties to enable pretty printing. This can be useful in for example in the development environment where we enable pretty printing and disable it for other environments. We set the configuration property grails.converters.default.pretty.print with the value true to enable pretty printing for both XML and JSON output. If we only want to pretty print XML we use the property grails.converters.xml.pretty.print and for JSON we use grails.converters.json.pretty.print.
First we look at the XML and JSON output when we don't enable pretty printing for a simple book resource:
We can group URL mappings defined in grails-app/conf/UrlMappings.groovy using the group() method defined for the URL mapping DSL. The first argument is the first part of the URL followed by a closure in which we define mappings like we are used to.
Suppose we have defined the following two mappings in our UrlMappings.groovy file, both starting with /admin:
Since Grails 2.3 we can use the url-mappings-report command to get a nice report of the URL mappings we have defined in our application. Also implicit mappings created for example by using the resources attribute on a mapping definition are shown in the report. This report is very useful to see which URLs are exposed by your application and how they map to controllers.
Suppose we have the following grails-app/conf/UrlMappings.groovy with a couple of mappings:
In Grails we can convert a request parameter to a type directly. We must then use the int(), short(), byte(), long(), double(), float(), boolean() or list() methods that are added to the params object available in our controllers.
Since Grails 2.3 we can also pass a default value, which is used when the request parameter is not set. In the following controller we use the double() method and define a default value of 42.0.
