Tuesday, February 15, 2011

Grails View as Spring MVC View

Introduction


The reference documentation of Spring 3 contains the following statements:

One of the areas in which Spring excels is in the separation of view technologies from the rest of the MVC framework. For example, deciding to use Velocity or XSLT in place of an existing JSP is primarily a matter of configuration. This chapter covers the major view technologies that work with Spring and touches briefly on how to add new ones.


The supported views are "JSP & JSTL", "Tiles", "Velocity & FreeMarker", "XSLT". Those are the major view technologies that work with Spring. The Spring MVC stack is usually : Spring MVC + JSP/JSTL + Tiles or SiteMesh. All these tools sound outdated, always usefull but outdated. On the other side there are frameworks like JSF, Grails, Play! (not exhaustive list) which come with great views more up to date.

Grails is the most logical choice because it uses Spring MVC internally. The task should be easier. To be honest this choice is not a very hard one because Grails view is elegant.

First step : web.xml


I basicaly replace the Grails dispatcher servlet with the Spring MVC dispatcher servlet. This dispatcher takes a configuration file, usualy named servlet-context.xml. There is no other specific configuration to do.

Second step : Configuring Grails



Grails has his own directories structure which is different of a standard Java Web Application. Resources resolver depend by default on this structure. Hopefully Grails supports WAR packaging so Grails can be configured to support a standard Java Web Application directories structure.

This configuration can be done through 2 files.

application.properties

This file is stored in the resources directory. It should contain :


The important line is grails.war.deployed.
Once set to true Grails resources resolver will use a WAR structure and Grails will cache GSP and not reload them. This parameter seems to be used for production mode only.


Config.groovy

This file is stored in the groovy directory. GSP reloading can be enabled with the following line :


Limitations

All the Grails taglibs cannot be used or should be used with caution. This is especially true for tags which use Grails controllers : g:form, g:link...
But creating a Grails taglib is quite easy.

Test sample

The Spring MVC controller


The Groovy server pages



This sample shows a Spring controller and a Groovy server pages. The GSP uses a UI composition pattern taglib I create (similar to facelet), a gsp template and a gsp layout.


Conclusion


The task is very easy. Nevertheless I lost quite some time on different things because of my poor Grails' knowledge. I created a custom view resolver and a custom context loader. All with some debugging to understand how Grails handles resources loading.

Nevertheless with these quite simple configurations you can use GSP as Spring MVC view. There are probably some other settings to do but for now this configuration seems to work perfectly.

The project is available on github.

In my opinion there is a big lack on the view side in the Spring MVC project. I'm really wondering what SpringSource is preparing.
Maybe a partnership or more ?.

4 comments:

  1. Nice article, but what do you mean by saying "these tools sound outdated, always usefull but outdated.", and then talking about JSF, which IS really outdated by means of approach of providing less control, complex unnecessary flow, overweight pages which are semantically wrong when HTML is produced and non-compatible implementations?

    Probably Grails is more fresh, I don't know, just starting trying, but I definitely can't name JSP/JSTL + sitemesh outdated, since they provide powerful control over end HTML, which is quite important for developers, crawlers and web-clients

    ReplyDelete
  2. Some of your statement about JSF are not true. Have a look at my benchmark, Primefaces is quite optimized and it renders a clean and a lightweight HTML. JSF flow has been improved with JSF 2 and you can used Spring Webflow or Seam.

    Yes, something can be usefull and provide powerful control over end HTML. It can on the other side outdated because newer tools provide more powerful control over end HTML and ease and improve the configuration and the developement.

    Grais view, Play! view (not exhaustive list) are in my opinion this newer tools.

    I encourage you to look at Grails.

    ReplyDelete
  3. MVC applied to WSGI or Java EE, is the Servlet a controller, dispatcher, or both? I think I've seen system diagrams where the controller and the dispatcher are different. Thanks for sharing your informative post.

    ReplyDelete
  4. Your posts is really helpful for me.Thanks for your wonderful post. I am very happy to read your post. It is really very helpful for us and I have gathered some important information from this blog.

    JAVA J2EE Training in Chennai

    ReplyDelete