18 September 2009
30 August 2009
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.
24 August 2009
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.
18 August 2009
- Grails is a framework which is good for getting your application running and grails is extensible with plugins.
- 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.
- 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.
- 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').
- 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.
- 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.
- 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.
- Do not create plugins overloaded with UI components. I would like to have one plugin bringing just one UI component into grails application.
- 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.