coding by convention vs prior convention

Been a while since I posted. I have still be doing some work with Grails and Java EE5. I completed out my test for UI's via AJAX as well but I thought I would put down some thoughts on coding by convention.

I am new to the Rails approach and I have to say I quite like it. The idea that the file system, file names and such carry meaning and that the framework uses these to look for things that might otherwise be designated in XML configuration files is quite nice.

Until of course you create a domain image. I created the domain image in Grails. This has the effect of telling Grails that any URL with /app/image in it should be processed by the controllers, services and such associated with that domain. Unfortunately this also means that img tags with src attributes that use /app/image in their path don't load images from a directory in that path, but that pass the request on to the domain controller.

It's a small point perhaps, but it does make me wonder what else I might run into. Domains with names like image, pdf or I am sure many other (conventional names) just might interfere with the convention of the framework.

Working on contrasting EE5 and Grails (Rails)

It has been a while since I did a post. I have been busy at work on some new architecture designs and intend to make a good entry contrasting Grails and Java EE5 efforts soon. However it has been a while and thought I would post up some errata thoughts I have had. It has been very interesting to see how the two efforts (Grails and EE5) deal with similar goals compared and contrasted to each other. Trying to do the same thing in two different frameworks has definitely made it easier to see how each is addressing needs. Of particular interest is comparing how grails deals with call backs from ajax widgets to server side logic compared to the Java Jmaki effort. I've got a longer post with my lessons from this that I am working on for a later date.

I must say I have come to really like closures. A programming concept I have not used much to this point. Groovy (which Grails is based on) does closures and I also found an interesting page on closures for Javascript. Ruby also obviously does this well.

I selected Grails over Ruby on Rails mostly due to the access I would have to the JVM combined with the Rails approach. Also since I was wanting to contrast against a pure EE5 approach this made more sense. By pure EE5 I mean an entity bean approach combined with JSF. With the hiring of Nutter and Enebo by Sun Microsystems, Jruby (another codehaus.org effort) could becoming an interesting option too since then "Ruby" will have access to the Java API's. It has that access now I believe, however I don't believe the Ruby and Rails aspect of Ruby is fully over to the JVM yet. I do like the coding by convention vs. the XML configuration approach however. I love XML, but think we have done too much with it in places where we could just use the coding language we have available. I definately will be looking at Ruby in general and the Ruby on Rails community more.

A very interesting interview is given by Tim Bray on InfoQ. It's a great listen for anyone interested in dynamic languages, RAILs concepts, ReST vs WS and some of the issues surrounding them.