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)?
No comments:
Post a Comment