I’m doing research whether Grails is a good fit for our new enterprise application. From your experience, do you think Grails is ready for enterprise application that has large volume of data transactions and many concurrent users?

Thanks.

Thanks for the example. I think you’re right about needing to think differently with the webFlow. I think what trips up most folks on the lists… myself included… is we keep trying to treat the flow like a bunch of controller closures that happen to be chained together not as a state-machine. I’ll definitely want to check out what you’ve done.

Webflow is wicked easy. I use it on my live production site. (I can’t mention it in open form but you can email for the addy or for a more complete code set.) I spent about two hours figuring it out. I sorta had to change my idea of request response since it’s just a state-machine. I had a few gotchas with the gsp’s. Since there is a flow state. So I did something like this to help men out:

(copy and paste bad in this little box)
Now controlling those actions in the flow is cool. Since it’s just a controller.

So here in one controller it’s for a registration page that someone has already registered: (some names have been changed to protect the innocent)

//register user
registeruser {
render (view:”userreg”)
on(“continue”){
def userreg = new User(params)
flow.user = userreg
if(userreg.hasErrors() || !userreg.validate()){
//FieldError – Spring Class
def emailReg = userreg.errors.getFieldError(“emailAddress”)
if(emailReg != null){
//flow.alreadyReg = “Yo Login here to continue!”
}
return error()
}
userreg.save()
}.to “makeGas”
on (“alreadyauser”){
flow.flaction = “fooaction”
flow.actbutton =”userlogin”
}.to “userlogin”
on(Exception).to “handleError”
}

Then in another controller reusing the same view:

startComplete {
action {
flow.flaction = “estimatecomplete”
flow.actbutton =”userlogin”
}
on(“success”).to “userlogin”
}

userlogin{
render(view:”/user/login”)
on(“userlogin”){
def userdef = User.findByEmailAddress( params.email )
def vshop = FOOShop.findByEmailAddress(params.email)
println (“vshop email>>>” + vshop)
if(userdef && vshop) {
if(userdef.password == params.password && userdef.emailAddress == vshop.emailAddress) {
session.user = userdef
flow.shop = vshop
}else {
flow.message = “Incorrect password for ${params.email}”
return error()
}
}else {
flow.message = “User not found for login ${params.email} or you are not a Verified Shop”
return error()
}
flow.user = userdef
flow.verShopId = vshop.id
}.to “completedEstimate”
//Become a FOO shop
on(“backtoreg”){
}.to “apply”
on(Exception).to “handleError”
}

The cool thing with webflow on spring is you can really get a lot of reuse out of existing views and domains. And they are not exposed. The url for the flow is sorta of annoying but you could jam that into a cookie if you really wanted to. (It screws up my analytics) but it’s a catch 22 with that sort a thing.

On a side note do use the compress plugin very nice filter. Try it out with the yslow plugin.

I may have rambled but I really like this stuff.
-Doyle

Yes, I like GORM a lot. Having worked with Hibernate and Toplink and raw JDBC, GORM is refreshing. Even my most esteemed colleague with PhD in CS – Srinivas Yellamraju (http://www.linkedin.com/in/yellamrajusrinivas) who is suspicious of all things magical and fashionable (he is still using Emacs!) – pronounced that GORM is clean. BTW, Y.V. learned Grails and Groovy by just glancing at my code in 1 afternoon, winces, and then proceed to build one of the most challenging module on the project. He still thinks that Groovy is “not quite LISP.”

We do like other parts of Grails – simplified Spring MVC, command objects, GSP, taglibs – all made life so much easier.

As for Webflow, we tried it back in Grails 0.6 (over 6 months ago), it was having problem working with Command objects, we logged a few bugs and rewrote the use case in our app that would have been a perfect candidate – it has a 4 form flow with multiple entry and exit points – we eventually wrote it controller logic using model state and conditionals. Not sexy, but it works.

It would be interesting to hear others’ experience on using WebFlow. IMHO it is still a little too magical – so when things go wrong, hard to troubleshoot. This is not a critique of Grails per se, but Spring Webflow itself. 2 years ago on another project, I tried raw Spring WebFlow and my feeling was the same – so I am on the fence with this one.

GORM is definitely the biggest win in Grails right now. I spent a little over a year using JPA before I discovered GORM and I think it’s the strongest point of Grails.

But then, Grails has many strong points. Not the least of which is the TagLib _authoring_ facilities.

Probably the _hardest_ thing for me to use right now is the WebFlow. Have you used this yet? I’d love to read your insights if you have any.

Grails shields you from dealing with Hibernate directly, while providing you the flexibility to bypass the ease-of-use layer to directly calls hibernate API, map POJO/POGO to tables/views/stored-procs, and/or issues HQL if necessary.

However, some conceptual knowledge of Hibernate or other ORM tools, and appreciation of their strengths and weaknesses would help with using it appropriately.

I personally find GORM (Grails’ ease-of-use layer on top of Hibernate) very easy to work with and flexible enough for our current needs, but I look forward to seeing GORM being decoupled as a standalone module so I can use it outside of webapps (like in a backend service), and also use it to talk to more than 1 DB at a time (current limitation). See Grails roadmap for 1.1: http://grails.org/Roadmap

Apart from programmatic and conceptual point of view, the configuration is also easier, but I suspect most serious usage would require more fine tuning of the various hibernate knobs and levers e.g. caching, connection pooling.