Listening to a discussion on Plone (http://www.twit.tv/floss137), a wonderful CMS built on top of Zope, I was reminded of our attempt to use Zope years ago. We wanted to replace a leave processing application written using Lotus Notes. We wanted an application written for a platform which would not have any constraints or issues regarding user licenses. Zope was sufficiently difficult to get started that we finally met our needs by using cgi scripts in Python with Postgresql as the database. If I were taking a decision today, the obvious choice for the platform would have been one of Django, TurboGears, Pylons or Rails.

However, application servers have not disappeared and products like Zope, JBoss, Spring continue to attract developers and users. It may be that with better documentation, exposure and smart development environments, application servers are no longer as intimidating as they were when we first looked at them. However, the application server developers cannot ignore the impact of the Rails phenomena. The following sentence from a Seam manual has remained in my mind:

“This(Seam-gen) is the easy way to get your feet wet with Seam, and gives you some ammunition for next time you find yourself trapped in an elevator with one of those tedious Ruby guys ranting about how great and wonderful his new toy is for building totally trivial applications that put things in databases.” http://docs.jboss.com/seam/latest/en-US/html/gettingstarted.html

Seam-gen creates a Seam application with a reasonable set of default parameters so that the developers can focus on the code and not worry too much about the initial configuration details. A J2EE application typically requires modification of xml files, an integral but painful part of the J2EE frameworks. With the incorporation of annotations in J2EE, writing code for J2EE frameworks, including EJB's, is much simpler. Hence, seam-gen is very useful as it helps get over the speed bump for getting started.

Another approach is to create frameworks on top of existing application server technologies. These frameworks may be especially useful in organisations which are already committed to an application server technology.

Grok -- now even cavemen can use Zope 3*.

* http://faassen.n--tree.net/blog/view/weblog/2006/11/09/0

Zope was the first object publishing framework. Zope2 was very successful, especially because of the Plone application. Incidentally, Canonical's Launchpad is another well known example of an application suite using Zope. Zope3's core is the Zope Component Architecture(ZCF) which emphasised modularity and scalability. However, Zope3 framework was not compatible with Zope2. Zope2 applications could not be made to run on Zope3 without significant rewrite. Hence, Zope3 did not dominate the new Zope deployments. Zope2 continues to be widely used as Plone still uses it. Plone did not migrate from Zope2.

The strategy of Zope3 framework was revised. The framework and the core libraries of Zope3 were separated. The core libraries were named as Zope Toolkit (ZTK). The original Zope3 was renamed as BlueBream. ZCF was backported to Zope2 making it easier for older applications to use the components framework selectively.

The flexibility and versatility offered by BlueBream implied a longer learning curve. However, with the separation of ZTK from the framework, it became possible for alternate frameworks to be created using the same base. Grok is a simpler framework based on ZTK which is pretty simple to use. The intention Grok is to expose ZTK to developers in a way that it is easier and more fun to use.

We will explore Grok in greater detail and how it compares with Django in a later article.

Grails – for J2EE shops

Not all components of an application need to have the same characteristics. A substantial part of the application may need to be friendly but scalability or performance issues are not critical. For example, administrative part of an application needs to be easy to use but it is rarely needed. Then, there are parts which may need to scale. It is also possible that we may prematurely optimise an application at the cost of delaying the release or making it harder to alter it in case the users' response is indifferent.

It is possible to use the same database as the backend but different frameworks for the different needs. However, it can be hard to sell the idea of multiple development environments. It can also be hard to sell the idea of a Rails or Django like environment to an organisation which is already using J2EE frameworks. Grails may be an ideal solution in such environments. It can integrate very well and fairly easily with existing Java applications. Grails is now a project of SpringSource, a part of Vmware.

It is built on top of J2EE technologies like Spring and Hibernate. It does not use XML configuration files. It uses the philosophy of 'convention over configuration' like Rails. It uses Groovy as the development language. Groovy, incidentally, is a dynamic programming language for the java environment. It incorporates many of the idioms of languages like Ruby and Python while adhering closely to the syntax of Java.

Given that the theme of this month is 'Cloud computing', it is worth looking at https://www.cloudfoundry.com/, a service of SpringSource, which offers hosting of Grails applications in Amazon cloud.

Grails and, especially, grok do not have the widespread awareness which Rails has. However, in certain scenarios, it may be much easier to use one of them and still get the advantage of a fast development cycle. Since both are built on established frameworks, the risk of using them is likely to be low to moderate. So, try one!