Thursday, July 22, 2010

Reading i18n messages from the database with Grails

   Many Grails based applications wants to read i18n messages from some other resource instead of from static properties files. Below link gives a great explaination how you can do it if you want to read messages from DB.

Monday, July 19, 2010

Comparing Grails and Tapestry

   Was going through some details of Tapestry to findout whats good/bad in it. Currently I am working with Grails based application for almost 1.5 Yrs. But believe me I would try to be very unbiased during this comparision.

Note: All the comments are my based on my personal likes and dislikes, so please excuse if you think otherway round ;). Your comments are welcome if you want to correct me or share your own experiences.

  Basically Tapestry and Grails both are  frameworks which gives you Convention Over Configuration platform where you can focus on your problem domain rather then settingup the environements for developement like Spring & Spring MVC configuration, Hibernate configuation etc.
  But  following are reasons why I still prefer Grails over Tapestry:

1. Tapestry is focused on UI development with Model based architecture in mind. Even though it says minimum configuration and more over convention, but didn't like the way we hare binding UI with backend as shown at when we compare it with GRAILS. I feel GRAILS is much more mature in many ways.
   a.  We will still have to manage all the Hibernate Mappings (annotations) by hand. Though we do it in GRAILS in GORM way, but somehow GORM ways makes it look much readable and maintainable.

2. Like Grails there is TRAILS as well. But dont see TRAILS group really active as there is hardly in Traction there. ex. look at the JIRA summary page:


3. Code in Tapestry still looks much more Verbose than in Grails. I mean we have to write relatively bigger code than in Grails.

4. I feels there are just ample of Grails plugin there are reusable components compared to whats are available for Tapestry based apps.

5. Environment based application behavior support in Grails is just too good to have it. Grails support to create custom environment as well that too without doing complex coding.

6. Its just too easy to write JSP taglib and template based apps which also changes relatively frequently in Grails and it can be use very extensively when you are developing a site which needs pages which gets data from multiple places and you dont want to hardwire your controller with all data.

     So basically I am not saying Tapestry is Bad. Its is good when someone is working on old frameworks like Struts/Spring only. But as a developer I would say, one someone starts working on Grails, would not prefer writing code in Tapestry atleast. Grails just so addictive ;) by its design and flexiblility :p

Some links for Tapestry:


Grails Intro by Scott Davis:

Thursday, July 15, 2010

Grails DB Sharding Plugin

Here is the link for Grails DB sharding plugin.

Lucene Search Index

  Sorry for not updating blog such a long time. May be I was just too lazy to do it. But I will try to not to be so lazy from nowon ;)
      Lucene is a framework which allows you to store some data that cab be indexed so that fast search operations can be performed on it. This data can actually from from any source like file system, Database, http etc.
     Data is stored in a "Document" form within by Lucene. Its is programmer's responsibility to get the data and create documents. Lucene takes responsibility to index it and make them searchable.
    Was reading on some articles to confirm the Lucene implementation in my Grails app is proper or not. Came across following few very good links for starters.