aspose file tools*
The moose likes Groovy and the fly likes Grails weak points Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Languages » Groovy
Bookmark "Grails weak points" Watch "Grails weak points" New topic
Author

Grails weak points

Johan Pelgrim
Ranch Hand

Joined: Jul 07, 2003
Posts: 105

Hi Dave,

We all know what Grails is good at, and what gap it is trying to fill. We can all read about the great features and what not, but... In your opinion what are the weak points of Grails? Where is Grails lacking, vulnerable or still a bit wobbly? Can you name say 3 points? And is anybody trying to strengthen these weak points in the (near) future?

Cheers,

Johan


Johan Pelgrim, The Netherlands
SCJP 1.4, SCWCD 1.4, SCBCD 5.0
Dave Klein
author
Ranch Hand

Joined: Aug 29, 2007
Posts: 77
Now this is a tough question. I can come up with three weak areas but two of them are based more on what I've heard from others than from my own experience.

The first one is a practical limit of one datasource for domain classes. There is a plugin that helps with this somewhat, but there are still limitations. I don't know if anyone is working to improve this other than the developer of the plugin in question.

Next, is the testing. This has improved significantly and I don't have any complaints about it but I've heard that Rails has better testing support baked into it, I know that there are several plugin developers working to improve the Grails testing story and they are coming up with some cool stuff.

Third, is the large stacktraces that you get with errors in Grails. They do get huge, but this doesn't really bother me (at least once I increased my console buffer size). This has also gotten better with some stacktrace sanitization in recent versions of Grails, but I still hear people complain about it.

There are other difficulties involved in using Grails, but nothing else comes to mind that could be pinned on Grails. There are just the inherent difficulties in web development. Grails alleviates many of these difficulties but not all... yet.

I hope that helps,
Dave
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Dave Klein wrote:

Third, is the large stacktraces that you get with errors in Grails. They do get huge, but this doesn't really bother me (at least once I increased my console buffer size). This has also gotten better with some stacktrace sanitization in recent versions of Grails, but I still hear people complain about it.


Interesting and Informative. Thanks Dave!
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3479

I find this post interesting:
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
It looks Groovy/Grails consume a lot amount of memory.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15300
    
    6

John Todd wrote:I find this post interesting:
http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/
It looks Groovy/Grails consume a lot amount of memory.


They do. I'm not sure if I personally would consider this a weak point. Memory is cheap and throwing more at an app is a simple fix. Future versions of Groovy, I'm sure this can be improved along with the help of the JVM. It's always a trade off though. I feel more productive with Grails most of the time and if that means I need more RAM, so be it.


GenRocket - Experts at Building Test Data
Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

Addtion:-

1. Memory :- I do not believe this was expected. Double the size of war file <not a big issue> and amazing amount of heap space and objects it holds. Brought down my production tomcat (shared with other Spring web applications). I have generous amount of memory, processing power and heap size (tuned)

2. Legacy database support *** :- I do not want to use standard id based tables or simple String. I had to do a lot of coding to take care of Complex composite keys with foreign key relationships. Also I do not like the way you have to query other tables (not in the domain)

3. Plugins :- Need to be more mature. Some basic plugins like searchable, filter pane, export work for basic feature. Well - I don't think any user uses these basic features and then you need excessive customization to get these to work for tech savvy user. For eg. Ms Access can perform better searches and filters. I have identified some bugs (may be fixed in the newest release)

4. Documentation and more examples :- I know the basics but some plugins and strategies don't always work as given in the documentation. Need more complex examples and tutorials.


===Vyas Sanzgiri===
My Blog
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15300
    
    6

So this is arguable not a weak point. Most Grails users would consider this a strong point and feature of grails, but I find it to be somewhat of an anti-pattern. I don't like the fact that in a grails GSP I can write groovy code. So for example...



Note Book.list(). This goes against everything I learned while growing up with JSP and the EL. You now have the ability to call arbitrary methods on objects directly in the view. And I think this is a horrible thing to do. I suppose this could have also gone in the Grails best practices thread in that I'd say a best practice is to avoid scripts in GSP like the plague.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15300
    
    6

I'd also like to +1 on the issue of Grails not supporting multiple data sources. Most (if not all) non java web frameworks do support this and while I understand this isn't an easy task, I'd hope to see it by Grails 2.0.
Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

Excellent points Gregg
Dave Klein
author
Ranch Hand

Joined: Aug 29, 2007
Posts: 77
Gregg,

I agree with your distaste for code in pages, JSP or GSP. That's one of the reasons I am so thrilled about GSP custom tags. They are so easy to create that there is never an excuse to put Groovy code directly in a GSP. For example the example you showed can be replaced with something like this:


Then in your GSP all you would have is this:

I know this is a contrived example but it does show just how easy it is to create a custom tag and keep code out of your pages.

It's also worth noting that you can add as many custom tags to that TagLib class as you want. Each one is just a named closure. And if you don't to use the g: for your tags you can add a namespace with a single line in your class:

then you would do this on the page:

You gotta love it!

Dave
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15300
    
    6

I do love it. I just wish Grails was A) promoted with doing this as demos and examples and/or B) didn't allow the alternative poor design choice. My opinion of course.
Raghavan Muthu
Ranch Hand

Joined: Apr 20, 2006
Posts: 3355

Thats a good example and explanation Dave. Thanks.
Vyas Sanzgiri
Ranch Hand

Joined: Jun 16, 2007
Posts: 686

I agree with both A & B more and more examples
 
Don't get me started about those stupid light bulbs.
 
subject: Grails weak points