Yann’s Blog

Its me again, and this time I bring news of lessons learned with the current development work on IRM 2.

Firstly, while EJB 3.0 is miles better than EJB 2.1, it doesn’t match up to a proper IoC container. By IoC, I am talking both about the Tapestry 5 IoC container, and the Spring IoC container. I find that with writing service methods with EJB, I spend far too much time both massaging domain objects between the EJB layer and the Tapestry layer - the Hibernate/JPA session is no longer valid outside of the EJB layer, so forget about all the “cool” stuff it does, such as lazy fetching, and wallow in pain replicating that functionality.

Second, component based view models are powerful, but not quick to grasp. I grew up (shame shame) on PHP, doing in-line HTML output. I know, this is bad, and I know better. I’ve grown accustomed to other view technologies such as templates (Smarty, Cheetah-Template, Velocity, etc), but still find myself taking a long time developing a workable component based model. This may be a shortcoming in Tapestry, but its taken me far longer to develop views than I would like. I will say that the component model is stronger than JSPs, but sometimes quick & dirty JSP gets you there faster. Some of this may be my experiences with Tapestry 5 talking, which I will discuss further below.

Third, Hibernate is amongst the best ORM wrappers available and a major time saver. Compared to other ORM wrappers out there (like ActiveRecord), it has an unmatched feature set, often backed by very mature Java technologies and libraries.

Java is a good language, and a fantastic environment. Yes, the language isn’t that great - overly verbose, no closure, a little too static. But the Java libraries available, especially on the server-side are un-matched from other web-development languages, including my favorite language, Python.

Groovy is a very promising language. Closures, duck-typing, first class JVM language, and more. Libraries that should have existed ages ago (XmlSlurper comes to mind). If you’re going to do quick development in a Java environment, or looking at a scripting solution in Java, give Groovy a strong look.

Whatever you do, avoid the creation of your own GWF. Also known as the Ghetto Web Framework. We’ve all seem them - you started out with some servlets, and went from there, making half-baked utility functions, some copy and pasting, etc. You get a maintenance nightmare - changes which should simply be a two-liner end up being propagated in odd places in your GWF, requiring exponential time to change. Plus your GWF is so tightly coupled to your application,  you can’t use it for the next application. There are so many web frameworks out there - please use one

Groovy on Grails makes an incredible rapid development environment. Coupled with Groovy, and with idea taken from  Ruby on Rails amongst other systems, you get an incredible Java development environment which is more productive and quicker to develop in than EJB, Tapestry, and maybe even the venerable RoR. Plus, its pure Java nature coupled with libraries such as Hibernate and Spring, you gain all the advantages of scalability and support that you just don’t get in RoR.

Wicket and Tapestry are very well organized frameworks. While I talked somewhat negatively about component based frameworks above, I would like to mention that both of these frameworks are fantastic in their own right. Wicket seems to be gaining a lot of momentum as well. But, on a negative note, Tapestry 5 needs more documentation. You can buy 200 books on Struts (though why you’d want to use it is beyond me), 3 on Grails, 1 (and soon 2) on Wicket, and 0 on Tapestry 5. Tapestry 5 really needs more developer momentum and support to come to fruition. Howard Lewis Ship is doing a fantastic job on being very careful and deliberate in his design and crafting of Tapestry, but he is after all one person, and can not do it all.

So, you may ask,  what does this have to do with IRM 2?

Well, I’ve been once again at the crank. I’ve realized that the code I wanted to avoid writing (simple CRUD), I am writing again, primarily through my mis-choice of EJB3. Partly contributing to this is Tapestry -  I’m writing a fair number of CRUD views - none of which are in any way exciting.

I’ve been converting the existing code from Tapestry/EJB to the Groovy on Grails framework.  Its been amazing easy to accomplish, and the Grails scaffolding support has been an amazing productivity boost.

Look for a developer’s release by the end of the year .

Till then

-Yann