First8 staat voor vakmanschap. Al onze collega’s zijn een groot aanhanger van Open Source en in het bijzonder het Java-platform. Wij zijn gespecialiseerd in het pragmatisch ontwikkelen van bedrijfskritische Java toepassingen waarbij integratie van systemen, hoge eisen aan beveiliging en veel transacties een belangrijke rol spelen. Op deze pagina vind je onze blogs.

Grails domain classes and special presentation requirements

In Grails we often use our domain objects directly as backing model for presentation purposes and only for specialized situations we create value holder objects or DTOs.

Beginning Grails developers know how to display individual entity properties pretty easy in a GSP, such as the name of a fictional domain class…



but sometimes struggle when new presentational requirements come in and slightly more or combined information needs to be displayed. Special constructions are contrived, such as the following:

to not only display the name any more, but also something else – e.g. its code. And that’s when things get hairy 🙂


This looks like a sensible way to get the new correct output in the browser. But it is not.

In this case entities are actually updated and leave the database in a very messed up state after a few iterations. This is the point where seasoned developers tell beginning developers not to continue down that road.

If you are one of the latter, read some of GORM’s persistence basics for some background first, and get back here for some guidelines you could use, in order of my personal preference.

My main rule of thumb is:

Do NOT replace data by a (re)presentational version of itself.

It’s not a fully comprehensive list, just to get you thinking about a few options taking our aforementioned BreedingGoal use case as an example.

If the information is contained within the object itself 

and you have the object, just format it right on the spot.

A GSP is especially useful for presentation purposes. I would always try that first.

Some people still get confused of the various Grails tags which seem to accept “just 1 property” of the domain class being iterated over, such as select

Luckily, sometimes the tag author thought about this 🙂 In the case of select, optionValue can apply a transformation using a closure:

If this new formatted information is needed on more places

to stay DRY you can put it in the object itself. In your domain class, add a getter:

which can be called as it were a property of the object itself.

If information is NOT in the object itself, but needs to be retrieved/calculated with some other logic

you can use a Tag Library.

In this example some kind of translationService is used to get the actual information you want to display.

A TagLib is very easy to call from a GSP and has full access to collaborating services and the Grails environment.

If there’s no additional calculation necessary, but just special (HTML) formatting needs

Get the stuff and delegate to a template:

where the specific template could contain some HTML for special markup:

Or you need to initialize a bunch of stuff once or you’re not really aiming for GSP display

you could create a (transient) property and fill it upon initialization time

Adjust the domain class, make your new “presentation” property transient – so it won’t get persisted to the database – and initialize it at some point.

Friendly word of advice: don’t try and litter your domain classes too much with transient fields for presentation purposes. If your domain class contains 50% properties with weird codes and you need the other half with associated “presentation” fields, you might be better off with a specialized value or DTO object.


You see there a various presentation options and depending on where the information comes from and where it goes to some approaches are better suited than others. Don’t be afraid to choose one and refactor to another approach when necessary, but I’d stick to the simplest option in the GSP first and try not to mangle your core data for presentation purposes too much 🙂

Original article