The first action packed day is over. I have written on some of the most interesting topics I attended sessions on yesterday. For details on:
- OpenSSO, see https://technology.amis.nl/blog/?p=3129
- OpenSocial API and Project SocialSite, see https://technology.amis.nl/blog/?p=3132
- EclipseLink, see Wouter’s blog and my comment https://technology.amis.nl/blog/?p=3131
In this article some shorter comments about the other sessions, including jMaki and Grails.
Groovy and Grails
Ironically, the best session of the day was one I did not want to attend. However, the queue for the OpenESB session was huge, so I escaped into the Grails session by Jeff Brown from G2One. And that was a very good presentation. The right pace, the right level of detail, demonstrations and clear explanations and a huge amount of enthusiasm. I am not a big fan of Grails, or at least I was not at the beginning of the session, but Jeff was very persuasive.
Grails – to be found at http://grails.codehaus.org/ – are an American instrumental rock band from Portland, Oregon. Well that too, the Grails we are talking about here is a web application development platform, based on the Groovy scriptling language and open-source technologies like Spring, Hibernate, Quartz and SiteMesh. (see also http://dev2dev.bea.com/pub/a/2006/10/introduction-groovy-grails.html for an introduction to Groovy and Grails by Harshad Oak). One quotation from Harshad: Grails can do to Groovy what Ruby on Rails has done for Ruby. And that is offer a ‘coding by convention’ approach that allows extremely fast first cut CRUD application development. In almost less than no-time you will have a not too bad looking CRUD (create, retrieve, update and delete) application for your domain objects. And where to me Ruby and Ruby on Rails are pretty alien technologies, Grails is much more friendly.
Groovy is one of the many scripting languages around that have attracted so much attention in recent years, together with Python, Ruby, Perl, (server side) JavaScript, PHP (?) and others. Groovy has been inspired by SmallTalk, Ruby and Python. One thing that makes Groovy attractive – although JRuby provides something very similar – is that it has been created for the JVM. In the words of Harshad: “The Java platform is concerned only with getting bytecodes to execute.
As such, the platform does not force you to use the Java language. As
long as you provide bytecodes, things will work. Groovy compiles to
bytecodes, and it makes no difference to the Java platform if the
bytecodes were generated from code written in Java or Groovy.”
This also makes integration between Groovy components and Java code very easy to accomplish: at run time they are one and the same thing (classes full of byte code the JVM can interpret). I was talking to Jeroen from Xebia at the NLJUG party and he explained to me how he used Groovy to quickly (3 hours) implement functionality that read from 9 different CVS files and merged them together into an XML file written out to the file system; he estimated that doing the same thing in Java would have taken two days or longer. Still integrating this work into the Java application his project was working on was a piece of cake!
Some key phrases on Groovy:
- is an agile and dynamic language (partly interpreted at run-time) for the Java Virtual Machine
- makes modern programming features (builders, dynamic typing and, yes, closures aka anonymous functions) available to Java developers with almost-zero learning curve
- supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
- makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
- simplifies testing by supporting unit testing and mocking out-of-the-box
- seamlessly integrates with all existing Java objects and libraries
Note: Groovy is picked by Oracle as the language to use for writing complex validation rules for ADF Business Components (see http://radio.weblogs.com/0118231/stories/2007/05/08/jdeveloperadf11gTechnicalPreviewTipsAndTricks.html and search for Groovy) and for command line access to the Enterprise Manager (if I remember this correctly, or was it Jython picked for this?).
Groovy has the concept of a GSP, the counterpart to the JSP. Building web applications with Groovlets and GSPs is similar to developing Servlets and JSPs (you guessed it) and can be used more or less interchangeably.
Jeff demonstrated in a smooth and inspiring way how he created a Grails application:
- create Person class and an associated controller which initially is ‘scaffold’ (generate plain CRUD support)
- generate Grails application, including data storage in in-memory HSQL database
- run application in Jetty container
these steps took less than 3 minutes and if he had not been talking he could have managed in under 90 seconds I believe.
He then showed how easy it is to implement find methods – the query is interpreted from the method name, such as findAllByAgeLessThan() – and define special URL mapping. Grails leverages Hibernate Query facilities for data retrieval, which makes it quite powerful and flexible. And as long as your requirements fit in the boundaries of Grails out of the box, you have tremendous functionality. And I have to admit that the fun in developing, that Scripting language adepts always profess in a somewhat over the top way, started to get a hold over me. It really looked like fun, primarily I suppose because of the speed and ease with which some non trivial features could be realized. Jeff demonstrated the concept of GSP Tag Libraries – smooth and simple, especially when compared to JSP tag libraries.
What I am wondering about – at least when it comes to Grails – is its focus on CRUD applications. What if you do not want a strict CRUD style application, what benefits do you then get from Grails. Can you easily extend from the first cut scaffolding Grails provides? Can you use Grails for the 60% of the application that can be regarded as plain CRUD and combine it with Groovy or Java (e.g. JSF) based web components? I suppose that is possible, but I have to look into this a little more.
jMaki – Building web 2.0 apps with jMaki made even easier
The jMaki presentation was done by no fewer than four presenters – which was not a good idea. While it was nice to have different angles, this was at least one too many for the 50 minute or so timeslot.
jMaki is an Ajax framework that provides a lightweight model for
creating JavaScript centric Ajax-enabled web applications using Java, Ruby, PHP, and Phobos. It provides widgets that are effectively wrappers for rich UI components from libraries such as Scriptaculous, Dojo, Yahoo, Prototype and others. It is extensible and allows us to create our own widgets.
From the jMaki home page
jMaki is a lightweight client/server framework for creating JavaScript
centric Web 2.0 applications using CSS layouts, widgets widget model,
client services such as publish/subscribe events to tie widgets
together, JavaScript action handlers, and a generic proxy to interact
with external RESTful web services. While jMaki abstracts much of the
JavaScript and CSS by providing defaults for widgets, the JavaScript
widgets and CSS are made easily accessible so they may be customized by
a designer or page developer. jMaki focuses on the aspects of
delivering JavaScript to the client allowing the JavaScript to
communicate to various server-technologies including PHP, Java
(JSP/JSF), and Phobos in a server-technology neutral way.
jMaki wrappers make it possible for developers to work with widgets based on components from many different Rich UI libraries in a consistent manner and even have those widgets communicate events and parameters.
jMaki also offers an XmlHttpProxy service that allows you to access RSS and RESTful services that are outside your application’s domain from the client. This is a challenge since browser security constraints do not allow the client to access URLs that are not on the same domain that served the page currently loaded in the browser.
To be worked on
Resources
Very nice article to get started with Grails: http://www.oracle.com/technology/pub/articles/grall-grails.html by Tug Grall.
The jMaki home page is at: https://ajax.dev.java.net/ .
Much material on jMaki can be found on Carla Mott’s blog at http://weblogs.java.net/blog/carlavmott/ .
