17 August 2009

What is wrong with UI plugins in Grails

Current era is about Web 2.0 applications which include at least customer oriented service (preferrably for those from the long tail) with a great UI above it. Grails is a groovy and java framework based on Spring which enables your next Web 2.0 project done in weeks instead of months. Grails delivers a new age of Java web application productivity as its official site states.

Disclaimer: before I continue it's worth mentioning that I am not going to say with this article "do not use grails as there is something wrong". I am using grails at my projects and highly recommend it to anyone looking at framework for quick prototyping standing on the giant's shoulders, i.e. Spring framework and Java. This article is supposed to attract attention to some pecularities which should be taken into consideration.

So, grails is developed based on convention over configuration paradigm and with DRY (do not repeat yourself) principle in mind. As the result we have the framework that makes it easy to quickly prototype your application - this is highly valuable for startups and companies which already have customers and are willing to extend the services offered to its customers as quickly as possible (time is money).

Lets take a simple approach to application development in which you have to develop domain model and then provide user interface to interact with domain objects. So what grails brings to domain model development and UI?

Modelling your domain in grails is really simple - all you have is to describe domain objects and relations among them - here GORM comes into play. GORM is backed up by Hibernate or JPA which come as plugins. Yes, it's grails ability to be extended by plugins functionality which makes it so flexible. You may use hibernate with any supported database, or use JPA and run your grails application on google appengine (what a great opportunity for startup), or even configure hibernate to use company's legacy many years grown database, or even you can develop a plugin to enable using java content repository (JCR plugin is being developed for too long).

And now it comes to UI for your applications. Grails offers us dynamic scaffolding, prototype as a library for using ajax in your web 2.0 applications and plenty of UI plugins. Dynamic scaffolding which can be tuned using custom css or even writing your own templates. It is strange to notice that there are still no 3rd party templates - it means that UI for real life application can not be entirely expressed with scaffold templates as scaffolding deals with CRUD operations that makes it widely used for admin areas and also for company's services where it is not necessary to pay so much attention to UI to attract new customers. So how about UI plugins?

There are lots of them: GrailsUI, RichUI, YUI - these plugins offer a wide range of ajax components for your site. Let's say you need an element to display rating in your application (good, there is Rateable plugin) and you choose RichUI as there is star rating component.

Now you end up with having prototype ajax library, which grails uses to add ajax behavior to forms and links, and yui library as it is required by RichUI. And is not there overlapping functionality in prototype and yui?

If you consider not using prototype (which above all is not a grails plugin - why?) you should stop using some of GSP tags which were so useful but which require prototype; or you may use jquery which comes as a plugin - what a great news. So you decide to switch to jquery: you have to install jquery plugin - that's rather simple, but to remove prototype stuff manually (remember that it is not plugin). But what if then you wish to install some UI plugin that is based on prototype - you would not know what happens untill you install this plugin and fail because prototype is in core (really was in core - remember that you've replaced it with jquery) and other plugins cannot show a dependancy on it.

And now take into consideration that jquery has a variety of plugins with a rateable component too - oh, there seems to be a lot of options for your UI. Is it great or does not it becomes a mess when you need a bunch of ajax libraries and plugins to create your app?

Disclaimer: choice of any ajax library is up to you and I do know suggest using A instead of B.

So, what can be done with so many cross dependancies in ajax libraries and UI plugins? Seems there should be Part 2 of the article.

2 comments:

  1. So what you are saying is that prototype (the slowest, clunkiest, feature-less JS library out there) should be a plugin? That is pretty easy to agree with, but someone needs to do the work to "make it so", the Grails core developers are doing what makes business sense from Springsource's perspective and fixing bugs for stability purposes at the moment. If you could grab the source and make a patch, I'm sure they would appreciate it!

    ReplyDelete
  2. It has been started as a discussion to understand if there are other issues that should be considered.
    Entirely agree that springsource has to make money from its products and services and I still suppose that Grails community should not just follow the general roadmap but also suggest new ideas wether like patches or just thoughts.

    ReplyDelete