Grass (Compass Css) plugin for Grails - new version released

Just released the next version of compass-css plugin for Grails. Now it is called grass, thanks to Robert Fischer for his idea on mailing list and permission to use this name.

What changed:

1. Plugin has been renamed to grass.
2. Issue with relatives paths to images in compiled css has been resolved.
3. Command for generation grid background image has been implemented.
4. ... and some other minor changes.

More details can be found on github wiki page or on grails.org.

Feedback is welcome.

Grail Podcast Episode 93: comments on my previous 3-part series posts and much more

Thanks to Sven Haiges and Glen Smith for their work in making grails podcats, which keep you up to date with latest news, trends in groovy and grails and for discussions they held. And I am glad that my three posts on "What is wrong with UI plugins in Grails" deserved mentioning and discussion in Grails Podcast Episode 93.

Also big thanks to Jeremy Flowers (@JGFMK) for noting this fact, he is really good being a Human Grails Search engine (as his twitter profile states).

Grails Podcast Episode 93 includes lots of interesting material, among which is "Testing OSGi Bundles with Pax Exam, Groovy and Gradle", "Groovy Stacktrace discussion", "Data Flow Concurrency in Groovy" and much much more.

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

In previous parts (here and here) I've talked about the current drawbacks in current Grails UI plugins. It should be noted that reasons for such a situation are not in Grails architecture (hope prototype would be taken out of Grails core soon), I suppose them to be due to: Grails is a rather new framework with a rapidly growing community and flexible plugin's infrastructure. As the result we are having a lot of plugins around and it becomes difficult to navigate among them and choose the proper set - a common situation for open source projects.

In the second part I have pointed out some suggestions on what can be done to improve situation with UI plugins. These suggestions are up to any UI plugin developer, whether to follow or not. But from my point of view any user of UI plugins would benefit if developers follow those guideline - still it is no more then some recommendations.

Now I would talk about what indeed almost every UI plugin is. I would rely on my experience of using jquery plugins, but I suppose there is nothing different in developing UI plugins based on other ajax frameworks.

Suppose we would like to create an UI plugin for grails which enables in place editor, so it would be jquery-inplaceeditor (following recommendations from my previous part of an article). What would it have underneath? There would be at least one javascript file, e.g. jquery-inplaceeditor.js, and if you want to use inplace editor via gsp tags then you will end having a file with custom gsp tag library. That is all.

Let's have a look at one of the recent plugins: flot. It is a javascript plotting library plugin I came across today. It is based on jquery, though it is impossible to say this just by looking at its name. If it were jquery-flot then it would be easier to figure out what it uses as ajax javascript library (besides, I have not noticed jquery dependancy in plugin.xml too - not so good). Plugin contains just gsp tag library and necessary .js files.

How would I use this plugin? I would move necessary gsp tags from plugin to my custom gsp library, e.g. ExternalTags.groovy (with namespace 'et'), and also copy necessary js files from plugin to my project. Why? Why not simply install plugin and use it?

In most UI plugins gsp tags are just another layer over js functions - you could simply use javascript functions but with gsp tags it looks cleaner. When developing UI of your application you end up making changes to those tags to include some extra logic necessary for your application. So why should you install plugin instead of copying and later updating some of gsp tags?

From my point of view current UI plugin structure seems to be redundant: every UI plugin has the common plugin structure with just several files located deep in it; in most cases those files (gsp tag libraries) are updated to match application needs.

It seems that injecting UI plugin dependancy is not necessary in application, because plugin's added value consists of gsp tag libraries which are modified prior to their usage. Why do not we treat it like a code snippet, a recomendation on how to use some javascript library in Grails project with an example of gsp tag library?

If we consider having a library of snippets for Grails project then we could change the layout folder structure of UI plugins (snippets). We could have just a folder for js libraries and a folder for recommended gsp tags (HOWTO on using js library in Grails project). For those who are still willing to inject such a dependancy into application there should be Grails command, e.g. install-snippet. And how about having a web application for sharing Grails UI snippets - all you need is to post gsp tag library and necessary js files or link to them (in most cases they belong to some javascript library)?

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.

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.