General Aspects of the Grails Application

[From the series - creating software books reviews grails web application]

In the previous post I have created empty "sbr" grails application. Before changing it to the real grails application it would be good to cover some basic aspects and communication flows of the more or less each grails application. This way it will be more clear what is happening. On the picture below I tried to write main aspects and communication flows of the grails application at least as I see them. I don't claim it is correct. If you need completely correct picture and definitions please refer to the Grails documentation.

Lets start from the top of the picture.

Probably as a first thing you want to display something to the end-user.

GSP stands for groovy server pages and is the view technology used in the grails. This means that front-end of the grails application is written in the GSP. To make GSP pages more readable and more scalable you can use TagLibs and Templates. As I like to write easily readable code, taglibs and templates are features of the grails that enables you to write readable GSP pages.

As the input into the GSP page you send a model. Just not to be confused, model is actually map of [key,value] pairs where key is the string and the value can be instance of any groovy or java class available on the classpath. Important part to remember is that value can be instance of any class - not only domain objects. I am making this clear because for the "long" time I was limiting data in the model to the instances of domain objects.

So when you are displaying GSP page, you are using gsp tags, custom taglibs, and templates. Data to be displayed on the page is contained in the model. Example of the map representing model can [bookToDisplay:book]. The bookToDisplay is the key (can be any string) while the book is instance of the groovy class. To e.g. display title of the book in the GSP page you would write ${bookToDisplay.title}.

Now when information is displayed there is big chance we want to send some data back to server and process it.

Controllers are groovy classes stored in the controllers folder. Each closure defined in the controller is considered as action and can be called from the GSP pages. So for example if you click the button on the GSP pages that is wired to some action in the controller, action in that controller will be called. Important thing to remember is that controllers are stateless. Controllers have access to the domain objects and to the services. This means, no business logic should be contained in the controller. Controller should use business logic available in the domain objects and services.

Data sent from the GSP page to the controller is available to the controller via params. params is actually variable containing all the request parameters. Thanks to the groovy it is injected into each controller so you have easy access to all request parameters.

So for example, if you have input field with the name bookTitle, content of the field is available to the controller via construct params.bookTitle.

Now when we got down from the GSP to the controller and we have all necessary data available via params variable the rest is easy.

From the controller class it is very easy to use domain objects and/or services. And when you are on the level of the domain object or service you are working with normal groovy and/or java.

Services are groovy classes stored within services folder. Services provide transactional context for database operations and can by dynamically injected into controller and domain classes. Business logic that is not directly connected with concrete domain object should be put into service. Additionally you can use service to surround transactional behavior around multiple calls on the domain objects.

Domain Objects represents domain of the problem you are solving. They are stored in the domain folder. They are famous because they represent GORM classes, grails solution for persistence. Domain classes are mapped to the databases and the database is automatically generated or updated for you according to relationships between domain objects.

And of course the whole grails framework is built on the top of the hibernate and spring. This ensures stability and scalability of the grails applications.

Summary

When you click on some button or link in the GSP page you are forwarded to the corresponding action in the controller. After performing basic validation in the controller you can use domain objects and services to perform application logic. After all necessary actions are performed you are creating model that is sent and displayed on the GSP page.

In the next post I will return back to the "sbr" project. I will create home page and explain basic layouting options.

P.S. Don't forget to write some review or post summary on the software books reviews.