At the Grails Exchange, Marc Palmer gave an excellent talk about keeping Grails one step ahead. This talk resonated a bit with the work we been doing in Secret Escapes for the last few months.
After having a little think about it, I feel like there are a few other things that would be nice to have to make Grails a easier choice for developers:
1. A Payment / Transaction / Shipping API ( E-commerce plugins ) – Right now, it is fairly difficult to add a Payment Gateway or Merchant Account. Tools like Magento in the PHP world do a fantastic job in abstracting away the details of integrating a payment gateway and merchant account. It would be nice to have a common API extended by all the different payment plugins. This would make it easier to build ecommerce functionality without having to worry about whether you are using BrainTree, Authorize.net or Satan’s favorite Payment Gateway, Paypal.
2. Internationalization API – At the exchange, I mentioned that Globalizing a Grails application is still a bit complicated. There seems to be a few plugins that set out to help localize domains and message bundles, but what seems to be lacking is a plugin like resources where you can go – “oh, I need to support multiple languages, I need to install the Globalize plugin”.
Message bundles simply do not go far enough in this respect. There still doesn’t seem to be a straightforward way to add multiple language enabled domain classes, url mappings or do ad-hoc language switching very easily. This problem was very apparent 4 years ago when I was building sites in Canada, and it is still true today.
3. Easier to customize scaffolding – The CRUD interfaces provided by Grails scaffolding are getting very nice. But it would be nicer if the scaffolding framework could be more extensible. If you look at the code of plugins like Flex Scaffold, there seems to be a lot of work being done for it to be similar to the default html scaffolding.
It would be nice if there was a common scaffolding interface that enabled adding rich client or mobile templates. It would also be nice if it was possible to add more template types, so instead of the typical ‘You can edit only one item at the time in separate screens’, scaffolding supported things like adding master-detail views, search and reporting templates and other types of alternative views that are automatically generated.
4. A/B Testing Framework – Working with frameworks like Google Website optimizer, it is pretty clear that a native grails A/B testing framework like ABingo or Vanity.
5. Member Services / Identity API – Working on a member’s only site for the last year has highlighted the need for a higher level framework for managing users. Nimble, Spring Security UI all provide a pretty good approach. But it would be nice if there was a common extensible core for this type of functionality.
6. Easier Reporting – on the business needs end of things, it would be nice if there was a slightly higher level page view tracking and reporting mechanism enabled. In our talk, we talked about how we built a simple engine that enabled us to store SQL / Groovy queries and render this out into reports. It would be nice to be able to easily generate summary reports and charts on domain classes, pageviews and similar mechanisms.
7. Content API / SEO – There doesn’t seem to be a lot of information about how to make Grails sites very SEO friendly. It would be nice if the URLMapping and Layout mechanism enabled easier customization of domain objects to inject specific fields like title, keywords and descriptions to domain objects. Also, having the ability to have sitemaps automatically provided and robots.txt templates provided would be very helpful.
Can you think of anything else?
Tomás Lin's Programming Brain Dump 
I think what is actually more important that all of these things – is either seriously trimming down the amount of “magic” that happens or having a good explanation of Grails internals. Make things simpler to grasp.
I would be nice if it is easier to understand Grails deeply and contribute to it, not just use. I would love to patch bugs in Grails myself if I only have any idea where to dig. Right now I don’t think anyone who isn’t active maintainer can dive into any bug without spending several days on research.
These are great ideas, and a lot of them would be best implemented as plugins. So then I’d counter with a question – how do we get the community enthused about collaborating to get these features implemented?
What I’m missing is a standard personalisation API that can be used to get parameters like theme, pagination size, currency and other user configurable parameters.
I really like ideas #1, #3, #6, #7. Agree also with Vladimir
‘s comment .
Most of your Suggestions target public web applications and sites.
Do not forget that Grails strength, compared to framework like Rails and Django, is its ability to be adopted by java enterprise infrastructure. Today, Spring is the only alternative framework and Grails is much more powerful and productive,
I don’t have any ideas currently but we, the grails community, must keep this in mind when planning the future of Grails
I agree with Fabien in that most suggestions target public web applications and sites. Would be nice to see a bit more focus in the enterprise. Spring Security plugin is great in this regards.
One thing I would like for grails applications is better multi – tenancy support.
For example, even a basic domain object (including its names and links) and its properties should be customizable easily. For e.g. a Customer domain object should show up as Patient for my hospital clients while it should show up as Leads for my marketing clients.Your slide on customizable themes in ‘A year in the life of a Grails startup’ addresses a similar pain I guess.
+1 for ecommerce abstraction, I think this would really plug a bit of a hole in the grails ecosphere. Perhaps best implemented as an abstract plugin.
Great discussion! Regarding Burt’s suggestion how to get the community enthused: Money talks? Would it somehow be possible to setup a market function on grails.org for donating money for new plugins or new features for existing plugins? Or is it a bad idea?
I am in a situation right now where I just don’t have the time to learn and develop new useful plugins. I might donate money if it can be justified though. There are probably others in my situation as well as them with more time and less money.
I hope you don’t get me wrong, I am extremely grateful for the Grails community and all the hard work behind it. I also try to give back as much as I can, whenever I can because I realize how much I have gained by making use of it.
Pingback: GroovyMag - the magazine for Groovy and Grails developers about Groovy programming and Grails development
A real good (abstracted) ERP plugin would be great. Especially, the folks that have a Grails enterprise wide web app that (are stuck with) and need to communicate with entities that are not web oriented like:
SAP!
Grails plugins still need improvements. I just created a version 2.0.1 Grails app, pulled in some plugins, but found some do not work. There should be a clearer way to indicate which plugins work with the release you are using. All plugins should have sufficient tests to verify whether they work with new versions of Grails, and those that do not pass should be flagged. Perhaps Grails should offer a modest monetary reward for plugins that supply thorough tests.