Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

[TSE] The Holy Grails of Web Frameworks with Guillaume LaForge

I only made it to the 2nd half of this talk because I got stuck in traffic on I-95.

Under the hood, Grails uses Spring MVC. It has support for "flash scope" between requests.

I find it funny that flash scope is so popular these days, we've had this in AppFuse for four years. However, web frameworks didn't add native support for it until it had a name (provided by Rails). To be fair to Struts Classic, they had support for it before Rails was even invented.

Rather than JSPs, Grails uses Grails Server Pages, which look much like JSPs. Grails uses SiteMesh by default and allows you to easily change the layout used with a meta tag.

<meta name="layout" content="main"/>

Most of the dynamic attributes in a GSP are rendered using the various "g" tags. There's dynamic taglibs for logic (if, else, elseif), iterating, linking, ajax (remoteFunction, remoteLink, formRemote, submitToRemote), form (select, currencySelect, localeSelect, datePicker, checkBox), rendering (render*, layout*, paginate), validation (eachError, hasError, message) and UI (i.e. richtexteditor).

Grails also allows you to write your own taglibs with a much simpler syntax. For example:

class MyTagLib
    def isAdmin= attrs, body-> 
        def user = attrs["user"
        if (user!= null && checkUserPrivs(user)) 

Then you can use it in your GSP:

<g:isAdmin user="${myUser}"> 
    some restricted content 

Is Grails Enterprise Ready?
Yes, because it uses existing Java libraries. Since you can create a WAR from your Grails project (using "grails war"), you can "protect your investment" and deploy it to your expensive app server. Although Grails is based on Groovy, it's a very easy language to learn for Java developers. In fact, there's hardly anything to learn. Most of the learning involves learning simpler ways of doing things. You can also use GORM (and its dynamic finder methods) outside of Grails. You can re-use the EJB3 annotated mapped beans and even the taglibs in your JSPs - it's all Java bytecode in the end.

More to come! On the roadmap: DSL for scripting Spring, plugins, flow/conversation concept with Spring Web Flow, JPA support, Web Services convention, customized URL mapping, JSP custom taglib support and finer-grained DB schema control. "It's up to you to vote for and prioritize new features!"

Books: Groovy in Action will be printing next week and The Definitive Guide to Grails will be out early next year. The existing documentation for Grails is 224 pages - so there's lots of information freely available as well.

My Thoughts
I didn't know that Grails allows you to generate Canoo WebTest tests for your UI. I agree that WebTest is an excellent way to test UIs, but I think Selenium is better. The major reason they're using WebTest seems to be because one of the WebTest guys happens to be a Groovy committer. I plan on learning (and hopefully using) Groovy and Grails in 2007.

The reasons for the Groovy and Grails projects seem kinda strange. I created AppFuse to solve my needs when starting new Java projects. Rails was extracted from Basecamp because it solved problems for DHH. Grails seems to be invented as a Rails clone. It doesn't actually solve a problem - except that Groovy needs a "killer app" like Ruby has with Rails.

Regardless of Grails' reason for living, I still plan on adding it to my toolbox as it seems like a very nice way to develop web applications. Maybe that's its reason for living? My question is this: do its developers use it to write real-world applications, or is this another project (like Craig McClanahan and Struts) where the lead guys don't actually write real-world applications? ;-)

Posted in Java at Dec 09 2006, 12:31:25 PM MST 6 Comments

As the "lead guy" I'll answer a few of your questions. I started Grails because I liked Rails, but couldn't use it because all of my existing software was Spring/Hibernate based. I had been using WebWork with Groovy actions for a couple of years before I started Grails and it was the natural next step.

As to whether I've built "real" projects with it. I have built several one is an internal e-learning script-to-screen technology that was originally a command line tool. I built a web interface onto it with Grails. Another is a custom CMS system for a leading HR company in london which you can find here:

They deploy several versions of the custom CMS for different portals. You'll find another one here:

Also several of the Grails committers are building real world apps for it including Marc Palmer who has several high profile UK clients

Besides that the motivations for Grails are much like the motivations for Groovy. I have a strong belief in Java as a platform, and all other scriptings languages (JRuby, Jython) don't integrate well enough with it. Plus I have a strong belief in the frameworks that have been successful in the Java world like Spring & Hibernate and didn't want to ditch that because I believe there significant advantages to using these.

Also, the major one for me is that I believe the whole dynamic vs. static typing debate is a red herring, and you get the most benefit by using a mix of approaches and Groovy as a language allows me to do this by letting me using Java when appropriate or Groovy when a dynamic approach is more suitable.

Anyway, I hope you try and enjoy Grails, I'd love to hear your thoughts when you have a real play with it.


Graeme Rocher
Grails Project Lead

Posted by Graeme Rocher on December 09, 2006 at 03:35 PM MST #

Thanks for your detailed response Graeme. It's great to know Grails is being built by developers with real-world experience. I expect great things from this project. ;-)

Posted by Matt Raible on December 09, 2006 at 03:44 PM MST #


I just want to add that I've "fallen in love" with Grails and it's a real pleasure to develop with. I don't claim that I'm a Grails guru, but slowly but surely learning it. Even though it's still in the development phase (0.4), I've been able to convince my management at work that year 2007 will be the "year of Grails" at Rutgers university!


Posted by Dmitriy Kopylenko on December 09, 2006 at 04:47 PM MST #

Hi Matt,

I'm the guy that happens to be the grails committer that is also the Canoo WebTest project manager. I would like to mention that the choice for as Grails functional testing tool is not only based on the coincidence of my occupation.

From the literally thousands of test tools out there you have to choose one and we have chosen the one that integrates best with Grails in a number of ways.

First, just like Grails, Canoo WebTest is model driven: you are modelling the expected behaviour of your application. This also aligns perfectly with the test-driven approach of most Grails applications since it lets you specify that expected behaviour before the functionality has been implemented.

Second, the descriptive nature of Canoo WebTest allows easy integration in the Grails scaffolding support.

Third, Groovy is a first-class citizen in Canoo WebTest allowing Grails users to leverage their knowledge in the language also for testing purposes. There is a specialized <groovy> step that allows expressing e.g. validation logic in Groovy, there are a number of ways to augment WebTest through Groovy (see the mailinglist), and last not least, you can specify your WebTests in terms of Groovy scripts!

No matter what test tool you like best, choosing Canoo WebTest for Grails makes a lot of sense.


Posted by Dierk König on December 21, 2006 at 10:01 AM MST #

Dierk - I agree that Canoo WebTest is an excellent testing tool. I've been using it in AppFuse and other projects since the summer of 2003! I saw the Grails Screencast highlighting WebTest and was quite impressed. Using Groovy to write the tests looks like a nice feature, but I can't help but think it has the same lack of code-completion features that writing them in Ant does. BTW - how did you produce the test report? Is it a Groovy-only feature, or is there an Ant task you can use?

Posted by Matt Raible on December 21, 2006 at 11:58 AM MST #

Concerning code completion, the situation is currently vice versa. You can have it for the Ant/XML flavour via DTD. Any decent XML editor (or IDE plugin) can do that. For the builder based Groovy scripting of WebTests, this is not available, yet.

There are thoughts in the Groovy project how to make builders capable of using code completion. When that is available, it's also automatically available when scripting WebTest but this will take some time.

Anyway, ease of writing tests can be achieved with the WebTestRecorder, which is a firefox plugin that acts pretty much like Selenium. Captured Tests can be expressed in various styles, e.g. Ant/XML or Groovy. see

Posted by Dierk König on December 21, 2006 at 03:34 PM MST #

Post a Comment:
  • HTML Syntax: Allowed