18 August 2009

What is wrong with UI plugins in Grails (Part 2)

In the previous part of the article I've talked about the usual way you have to go when getting acquainted with a bunch of ajax UI plugins that you might want to use in your grails application. Let's summarize the key points:
  1. Grails is a framework which is good for getting your application running and grails is extensible with plugins.
  2. Plugins come to play when you want to quickly bring some cool stuff to your greates web 2.0 application (surely they are other plugins too that have nothing in common with UI but we will not talk about those plugins). There are UI plugins that you may choose from.
  3. Grails ajax UI plugins are dependant javascript framework. The good thing is that it is possible to manage plugins dependancies, so at least when installing UI component A grails will install necessary javascript framework.
  4. The bad thing is that prototype ajax library which is used in grails by default is not a plugin - it is in grails core. That is why UI plugins can not state a dependancy on prototype.
  5. Is impossibility to state a dependancy on prototype is so bad? Not really until you do not take in mind your web 2.0 application load time and at some moment decide to minimize the number of ajax frameworks used in your application. On this stage and so on you should be very careful about removing prototype (if you've decided) and installing some other UI plugins (remeber that there is no dependancy on prototype - so they will be installed 'successfully').
  6. UI plugins bring to developer a lot of cool UI components that overlap between plugins (go and find how many plugins offer autocomplete feature) - so with one or two so necessary components you get a number of unused (for free surely). As for me I do not like having much unused code in apps, if it is unused why should we keep it? That is why choosing between grails UI plugins is a terrible excercise that makes you also keep in mind plugin dependancies on ajax libraries.
As for me after looking through grails UI plugins I find my self using jquery with those plugins (jquery plugins, but not grails plugins - those that are not available via grails install-plugin) I really need, when every plugin for jquery is responsible for just one UI component. (Disclaimer: I'm not into holy war devoted to ajax framework - jquery is just my choice)

Ok and now what? What is from my point of view a way out current situation with UI plugins?
  1. It is necessary to take prototype out of grails core and make it a plugin (grails core plugin, just as hibernate). It would make possible to make UI plugins dependant on prototype.
  2. It would be even great to create right now a stub for prototype plugin while still having it in core so that new plugins could be dependant on it and there is some time to update those plugins that we already have.
  3. Do not create plugins overloaded with UI components. I would like to have one plugin bringing just one UI component into grails application.
  4. Use common naming (it should be considered a good practice) for plugins with UI components, e.g. yui-autocomplete or jquery-autocomplete, so you can quickly say what ajax library is necessary and do not have to dig into plugin.xml.
Ok, these points are stated from the point of a developer who is using UI plugins. In the next (I hope the last part) I would talk about developing grails plugin with UI component and the ways it can be made more efficient.


1 comment:

  1. Good point. This is one of the things I've been sot of struggling with too. If you look at Navigation/Rich UI, again it sounds like overlap.
    I think these UI plug-ins are great for learning the ropes, but sooner or later, people will resort to falling back to something like YUI itself and not use plug-ins. Sven eluded to this to some extent in one of the podcasts as to how he codes in Grails himself. It came from a listener asking can you mix and match UI plug-ins I beleive.

    ReplyDelete