Slashdot Mirror

I would not recommend Grails at all. First, if for no other reason, it's a bit player, so good luck finding developers, tools, help, and all of the other benefits you get with using a language/framework with a large, thriving community. That alone should be enough to steer you away from using it for enterprise anything.

Aside from that, boolean truths are quirky, to put it kindly.

Null evaluates to false, which is ridiculous and doesn't eliminate the need to check for null, just hides the problem if you forget to do it. This is because groovy uses "null objects." Null objects mean yay! no null pointer exceptions, but the consequence is... no null pointer exceptions! So have fun tracking down bugs when things fail silently.

Variables defined in closures (which is most of them) are opaque, so you can't easily inspect them without printing them out or logging them. So now you have no NPEs and no easy way to check for null values versus empty values while debugging without adding debugging code into production code. Ugh! Don't forget to annotate the debug code so you can remove it when you're done.

You don't get compile-time errors for things like using undefined classes/methods (typos!) or sending the wrong argument types. Instead, you have to compile, run, and look at massive stack traces throwing up all over your console/log: http://pastie.org/583115 Then rinse and repeat until it actually runs. And that's before you even start testing actual functionality.

Method entry and class loading breakpoints aren't supported. (This is simply an inconvenience most of the time, but it's worth noting IMO.)

Conversely, since groovy uses convention over configuration, IDEs may flag things as errors which are not. IntelliJ IDEA probably does the best at handling Groovy/Grails, but it still has some issues. My experience was that Intellisense/autocomplete didn't work reliably for Groovy in any IDE, so if that's important to you, you may miss that.

It's not clear where business logic should go. http://bartling.blogspot.com/2...

It's buggy. https://jira.grails.org/browse...

To be fair, I'm heavily biased against dependency injection, dynamic typing, and coding by convention, which are the very concepts Grails is built around. I could go into all of the reasons, but any flamewar worth its salt will list them all for you.

Better design helps with a more flexible codebase. Having to code around Drupal rather than just placing controller/model/view in their appropriate directories and allowing the container to manager plugins for ACLs/etc, can create a spaghetti coded nightmare in the longrun. Sure you can whip up code samples quickly but is it a longterm, maintainable and extensible code structure? No because it lacks structure. This is something that a framework provides.

Go GROOVY/GRAILS!! (my plug)

after reading most of the comments I can sum it up:

Optimistic Locking: described here by many readers, easy to implement, also good idea to implement first even when using other scheme. It will piss off users from time to time, though, because they loose data. This is the choice of the (lazy) developer and/or the cheap customer.

Real row-based or even finer locking: Hard to implement right with all the timeouts, user-infos, keeping unfinished edits over sessions,.... This is the choice of the demanding user that doesn't want to loose any work at all, and the wise customer.

Realtime concurrent editing: not really sure about this.

Ramble on, guys.

You'll be surprised how many use cases just doing Optimistic locking can solve. In a framework like the one I use Grails GORM there are even ways to implement custom UI handlers for the collisions so that users don't really lose data at all. The data is still "in flight" and you can direct it through many different workflows and business rules before it gets saved. You can do all this on a case-by-case basis as you need to.

Discover TPS report collisions are easily merged? Do merge on TPS reports. Discover you need to do a fancy edit screen when looking at Foo records? Do complex versioned edit screens on Foo records. Discover you have to do special semaphore and locking on complicated workflow based processes? Do that in the controllers for those...

This is a pragmatic approach that acknowledges much more sophisticated systems of locking are usually YAGNI (You Ain't Gonna Need It) and you spin up developer time when you find out you really do need it. Spend developer time solving *exactly* the problem you need solved and not doing complex general solutions that you will never need or only need for one event every decade.

Your summary betrays your bias. I think you probably invented a very sophisticated system that is so much smarter and better than simple poor Optimistic Locking and you are in absolute love with your idea. You didn't want the slashdot crowd to help you... you wanted us to tell you how awesome you are and tell you what you were going to do was super and we all want to do what you did.

Well. I'm not as arrogant as you. I invented a locking system involving a separate lock table, a lock time out, a flagging system for users, and all sorts of sophisticated things that let me do amazing stuff with locks. It was a huge development effort... Optimistic Locking with no UI resolution code beyond "oops" was ready for slip-stream to production in a week. Guess what... the pain of the edge cases where pessimistic locking is the "best" solution? They didn't care after the basic Optimistic Locking was in place. I was forced to concede that I was wrong... I learned something.

Can you? From how you summarize this thread I don't think you really are learning.

Heh. I'm going to post it again after all. http://grails.org/doc/1.0.x/guide/single.html#5.3.5%20Pessimistic%20and%20Optimistic%20Locking - leans on the underlying J2EE to accomplish this. A good framework should provide at least the underpinnings for this and I'm in total shock that people even *start* development today without knowing this stuff.

Awesome post. I like the description here: http://grails.org/doc/1.0.x/guide/single.html#5.3.5%20Pessimistic%20and%20Optimistic%20Locking but it is lacking the performance analysis commentary you have made.

Since this isn't "in the box" with web app frameworks

Woah look what's in the box: Grails Guide: Pessimistic & Optimistic Locking ... that's a built in Hibernate feature common to all Java frameworks... for some reason I thought *all* frameworks had that baked in. Look Ruby on Rails has this too proving how AWESOME it is.

What *lame* frameworks don't have this?

if they can get as functional as tomcat then you can run Spring on it. That counts as J2EE. They also have this thing called Grails which seems to be a web-dev system built around Groovy.

Those layers upon layers were a result of decades and several agreed upon standards.

If they are too complex for you simply, make them easier. The complexity isn't an excuse to throw out everything achieved so far and recreate the wheel, the transmition, engine, driving interface, etc...

Groovy for Grails http://grails.org/ which is based on Java/Hibernate/Spring is an excellent alternative to Django.

It's just about choosing the right tool for the job.

Django has an Object-Relational Model built-in to the system. Programmers write a models.py module full of ORM classes. Then, the Django utilities build SQL database tables to match the models. The Django Object-Relational Model has no equal so far as I've seen.

Django enforces the MVC web application. Most other web frameworks let the bad habits creep in.

You have just given the exact same list of reasons I chose to use Groovy/Grails over Ruby on Rails. You have peaked my interest. So I will definitely have to take a look at Django. Especially now that there is a Django plugin for Grails: http://www.grails.org/DjangoTemplates+Plugin ... I have a couple of toy projects I may choose to do in Django to get a feel for the framework...

Wicket is pretty cool.

If you haven't already, check out Groovy and Grails. They will change your life :)

I'd use none of the above and opt for Grails http://grails.org/ which gives me the java app servers (jboss, glassfish, tomcat, etc), the huge Java class libraryand the Groovy dynamic language. Seriously, if you are looking at these technologies do yourself a favor and be sure to check out Grails.

Is the part about grails... This is starting to look intresting, and would allow me to combine my lust for Ruby on Rails with my knowledge of all things java... And since it runs in a J2EE appserver I bet companies would actually use it... Groovy is looking very nice now that they have figured out some of the syntax issues... I would love to have closures and method injection for some of my code, and typesafe java everywhere else...

In TFA there is a link to Grails http://grails.org/ , which is slightly different than jumping on the Java bandwagon. The Grails base is Groovy http://groovy.codehaus.org/, which is a promising (still little immature) dynamic language. I think Java developers better take a look on the changing world, otherwise they will end up as their COBOL ancestors. Similarity: how many big-iron J2EE servers were 3 years ago, and how many were "upgraded" to Dells running whatever-app on Linux.