PDA

View Full Version : CRUD: Grails or Roo



mschipperheyn
Sep 1st, 2009, 08:38 AM
Hi,

I need to develop a CRUD application for a fairly extensive jpa based datamodel (including m:n, inheritance etc) that is currently using for the frontend Spring 2.5.x, Hibernate and Freemarker.

I need to develop a backend for it and I have for a long time been looking for a CRUD type environment that allows me to quickly get a full featured CRUD app up and running.

I have looked at stuff like OpenXava, Krank (1.0.5), Grails, Skyway and Roo. Originally I started from the premise of re-using my existing jpa model but I have since dropped that requirement. Might as well consider re-creating jpa classes if that means a speedier overall development.

So far, Krank was the most impressive in terms of allowing me to create a structured java application (maven, etc) and having an advanced ui which allowed for filtering, sorting, in context 1-n creation etc. Basically, what you would expect from a backend out of the box ui. Unfortunately, Krank seem to have been abandonded.

OpenXava has an equally impressive rich feature set, however, it doesn't allow for a structure project setup (it comes with an entire tomcat setup attached to it) and the source code doesn't look very cleanly separated.

Skyway I just couldn't get to work it's magic for me.

Grails looks impressive in terms of the cleanliness of the code and the code by convention approach. However, when it came to the generated ui, the convention seems to have been thrown out of the window a bit. Editable primary keys, no filtering on lists, a date ui element from the 90s and no in context 1-n creation etc. When I saw it first, the horrible hello world feeling crept up on me that seemed to be the staple of Java frameworks since well, since before gwt: a text field, a checkbox, a radio, a pulldown. I was disappointed. Still, the cleanliness of the code suggests that these things could be easily created and then there is the plugin eco system which seems to offer many nice features. Personally, if code by convention is the aim, a few of the features should imho be out of the box.

What I saw of the Roo UI comes a bit more from screencasts and a first hello world experiments but seemed a bit more advanced. Normal date components, cool numeric filter etc No in context 1-n creation no list filtering.

It's a given that many framework architects and developers place a higher value on the plumbing then on the ui. And then there is the fact that neither Roo nor Grails intend to be an out of the box CRUD framework. However, they do both boast the intention to significantly increase productivity.

Ok, so here's (finally) the question: where is Roo going in terms of CRUD? Are you aiming to scaffold to the point of having a functional CRUD ui generated out of the box or are you going to do a bit of CRUD but not useful enough for production use? E.g. If I have a List with 1:n Tasks, am I going to be able to create, list, filter from withing the List form or are you just going to give me a pulldown with all Tasks? How far in terms of roadmap is the scaffolding going to go?

I've also heard a lot of "well, if you can choose, go with Grails but if you HAVE to use Java, go with Roo". In a year from now, do you think Roo has the same productivity or perhaps even more than Grails? Also taking account out of the box ui functionalities, plugins eco system etc

Kind regards,

Marc

Stefan Schmidt
Sep 1st, 2009, 07:25 PM
Marc,

Roo does currently offer view scaffolding for standard CRUD functionalities. This means you would typically design your simple Pojo (including constraints used for Validation as well as JPA relationships), then have Roo generate a RESTful controller for it along with the view artifacts (JSPs are supported currently). Furthermore, Roo will generate fully functional integration tests (JUnit) and even a selenium test suite. There are many more features available and even more planned. In short, Roo will generate and manage a fully functional CRUD application including UI and backend. To see it in action run the 'script clinic.roo' command inside the Roo shell and then quit the shell and start it with 'mvn tomcat:run'.

If you want you can do all of these things from the Roo shell (next gen command line application) without having to fully know or understand technologies like Spring, JPA, JSP, Dojo, Validation API, transactions, logging, tests, etc. Roo generates a complete maven-based project which can be easily handled by your favorite Java dev environment. The SpringSource tool suite offers currently a very nice feature set to make working on Roo projects convenient. It also ships with excellent integration Roo to the Roo shell itself.

Roo generates not only CRUD functions (persist, findX, findAllX, merge, remove) for managing and persisting your domain objects but also convenience methods to enable paging (findXEntries(int firstResult, int maxResults)), as well as dynamic finders (findXsByNameAndWeight(...)). There are more features planned and we welcome feedback and suggestions from you!

HTH,
Stefan

mschipperheyn
Sep 2nd, 2009, 02:43 AM
Looks very nice so far!

I think the four most important missing features for me are:
* Integrate finder functionality in List view.
It also cleans up your user interface by removing all this find by menu items

* List 1:n, m:n, 1:1 using the list view in context (including filtering and sorting). On any normal size database pulldowns quickly become a nightmare. And how would you create a new record with a required 1:1 value for this and having this value need to be created with the new parent record?

* Allow users to create a new in context 1:n, m:n, 1:1 new object references
This is way more efficient. See also Krank, OpenXava etc

See http://krank.googlecode.com/svn/trunk/docs/images/paginated_filterable_listing_feature_map.jpg for an example of how I think it should be done
and
http://krank.googlecode.com/svn/trunk/docs/images/master_detail_pic.jpg

* Pagination seems to be missing on the default lists. I think pagination should be a default 20 records per page

Nice to have
* Not sure if a Spring Security user/pass front is available, but that would be a nice configuration option
* A Freemarker based front would be nice

Bugs
* Visits aren't saved on script

Shell
* Moving cursor around is hard to do because the cursor isn't visible when moving it.
* script clinic roo: bad version number errors when java_home is set to 1.5. Prob good to have some warning message in Roo when you start it up

Cheers,

Marc

thobson
Jun 3rd, 2010, 11:50 AM
We recently posted a blog entry (http://www.raptorconsultants.com/spring/grails-vs-roo/) on the subject. Our general preference is for grails but we do like the look of roo

rohit_virbhadre
Sep 30th, 2011, 04:28 AM
Hi

I worked on Grails for 1 year and I am working on Roo for last 6-7 months,
I think CRUD in Grails is good than roo because,

Roo is good when you are developing basic CRUD applications and real life applications are not basic CRUD's.
Customization of roo is not that much easy.
Roo is using jspx and jspx is not having all standard tags in it. So you must have knowledge of tag library to update or develop new tagx.
No proper documentation of jspx is available.
Using jQuery or Ajax is not that much easy task.
You need to change views completely if you want complete flexibility of HTML tags , JSP tags, JavaScript, jQuery, and Ajax.

As Grails is providing simple jsp as views.
Using Ajax and jQuery is very simple.
Message handling is very good.
Controller code is easy to understand and edit.


Thanks & Regards,
Rohit

delgad9
Sep 30th, 2011, 09:05 AM
Pluses on Spring Roo over other RADs...

At the end of the day SR is plain old Java -that we love very much-. You don't have to learn another programming language just for doing web development.

Real world requires performance. With Java all computer muscle is used in your application. There is no overhead for translating from another programming language into Java.

Additional points here http://forum.springsource.org/showthread.php?76633-Is-Spring-Roo-production-usable-right-now-Or-is-it-too-soon on delgad9 entry.


Thank you
jD

praskrishna
Apr 18th, 2012, 05:48 AM
We had a requirement where we had an application in production and was developed in Spring MVC and the velocity of developing new features were slow. We had to explore alternate frameworks like Grails and Roo. I personally spent close to a month exploring which one was better.

If you want to see the details of the analysis visit @ http://ramya.bhaavana.net/krishna/?p=63

We explored following features in both these and below is our findings. The final verdict is we have still not finilized on either one, we are still exploring

delgad9
Apr 18th, 2012, 06:44 AM
@praskrishna,

I just added a couple of points on the Spring Roo side...
These points in my opinion complements your evaluation.

B. Roogards
jD @ http://pragmatikroo.blogspot.com