I’ve released another Grails plugin

Witness the power of the bean-fields plugin for Grails!

<bean:withBean beanName="form">
    <bean:field property="firstName"/>
    <bean:field property="lastName"/>
    <bean:field property="company"/>
    <bean:field property="email"/>
</bean:withBean>

This will render input fields of the appropriate type, with sizes set according to the fields’ constraints, select field items from inList etc. It also renders label tags, errors local to the field, and required indicators.

You can customize the markup used for all this stuff, so that you get a consistent and noise-free rendering of fields across all your GSP views.

Please do check it out and let me know if you have any issues.

Development is easy. Creating product is hard.

I’m working very long hours at the moment. By day I work on Weceem CMS and by night I am acting as the architect and producer of a new web service that I am developing with some friends.

Of course the web service is being built with Grails – it would be insane to use anything else! Chris our developer is doing an excellent job – Grails is massively empowering. In the timescale we’ve been working to an amazing amount of stuff has been achieved – even when some of it is being learned on the job.

Oh and of course the core idea is there but the details are being fleshed out as it is developed, but Grails reduces the pain for Chris as changing direction on some features is not as heartbreaking as throwing out weeks of work on thousands of lines of code.

Our designer Pat is also working well with editing GSPs directly, something new for her which she is enjoying, along with learning the joys of Blueprint CSS and jQuery UI.

However, what was obvious to me before starting this project, is painfully obvious to me now. Modern tools like Grails take the classically hard part of making a software product and turn the problem upside down.

We don’t spend time fiddling around with config and trying to glue various tech together, writing reams of bean accessors and lame JDBC code etc. – we spend all our time trying to meet the challenge of creating an application that really makes sense to users, hides all the technical detail – while providing features that a few years ago would have been considered very low priority due to the work required to get even the basics off the ground.

Expectations of modern web apps, especially the expectations that come from ourselves as designers and users of such services, are very high.

This is however a “high quality problem” compared to chipping away at a massive mountain of code just to get something half-assed ready, and deferring all the parts that are important and useful to end users (and hence ultimately the business) until later.

Time is of the essence. Grails cuts out maybe first 3 months of dev, and we focus on the business problems.

It’s a no-brainer in that sense.

Weceem 0.1 to 0.2 – changes under the hood

We released Weceem CMS 0.2 just before I went away on holiday a couple of weeks ago, so I haven’t had time to write anything about it until now.

Weceem is a CMS written purely in Grails, using Grails plugins as much as possible. It has some history at jCatalog AG who have worked on the code and core concepts in various forms for a while now, and for the last 10 months or so I’ve been helping them out with Grails approaches, architecture and a little coding.

We didn’t want to write another CMS just for the sake of it. Lord knows there are so many out there, its almost painful to write another. However we believe we can bring simplicity and novel functionality to the CMS space that is missing in other Java-based CMSes. (Perhaps this is the folly of all who re-invent the wheel?)

Release 0.1 was a line in the sand, whereas 0.2 includes some major overhaul. It took a lot longer to get to 0.2 than we intended, but there were some major changes behind the scenes, aside from bringing it up to Grails 1.1.1 compatibility and splitting it out into a Grails plugin and an app, so you can embed it in your own Grails apps or use it standalone.

Here’s a brief write-up of some of the changes we made, and why. There is also a short screencast that shows these changes here.

Reworking the admin UI

The admin UI desperately needed some love, and we want to move to a much more contemporary and less “Windows app” like feel. Something that is bright, bold and clear.

We also greatly simplified it, reducing the number of screens. We are for the moment at least using BlueprintCSS for the structural layout of the admin UI. It has been a major timesaver for us coders who, if we are honest are not the best cross-browser CSS designers.

What we’ve done so far with the admin styling is begin the migration away from the old UI. The work is by no means complete yet, and the UI will be more polished in time. We’re very much focusing on getting the bare bones functionality working well first before we do anything too fancy with the visuals.

Switching to jQuery and jQuery UI

A wide mix of tech was used in 0.1 for legacy/RAD/prototyping reasons, resulting in a fair amount of bloat, and slow page load times.

As a result we ditched all of the Dojo/Dijit/Dojox stuff that was there and complete rewrote the UI in pure jQuery and jQuery UI. Our code is wonderfully lean now.

We looked at all the libraries out there and decided on jQuery. Its “where its at” as far as we’re concerned. Unfortunately we have had to use a “non-core” tree table widget and some custom behaviours for the draggable content repository, which is currently a bit ugly in places – but it is a work in progress that improves greatly on the old tree UI.

We still have some cross-browser glitches eg badly floated button icons in Safari and a few layout “blow outs” that we will fix in time. Any help with these jQuery UI style issues would be much appreciated – I haven’t received any help on the jquery ui mailing list about the Safari icon issue in particular.

Dynamic content editor

In 0.1, which had effectively evolved from a prototype, each content type had its own controller and views for editing, with lots of duplication. Much of this was modified scaffolding, and we all know that while scaffolding is great for helping you to build a house, nobody lives in a house and leaves the scaffolding up once the work is done!

Extensibility of content types in Weceem is very important to us. So in 0.2 we introduced a dynamic editor framework. There is a single controller and view set for editing all content types in Weceem now.

We achieved this by using some convention properties on the content classes to declare which fields are to be presented in the content editor, and how they should be rendered.

Because of Groovy’s wonderful dynamic abilities and Grails taglib support, we are able to render any custom editor you may wish to use on a content field – you just have to supply a Grails tag that follows a specific naming convention, and use the correct name in the editor declaration of the field in the content class.

For example, rich html editing as used for the “content” properties of HTMLContent and WikiItem, is achieved by specifying the “RichHTML” editor:

static editors = {
    template(group:'extra')
    content(editor:'RichHTML')
    keywords()
}

The editor then invokes the editorFieldRichHTML() tag when rendering the “content” field of a HTMLContent node in the editor. Its as simple as that. We also have hooks for custom editors to pull in extra resources in the <head> section of the page, such as JS and CSS files.

We have grouping of fields into the “Extra” section, and perhaps more in future, and you can force the hiding of certain properties.

This mechanism works with inheritance, which we use heavily in the content model – although the details of precedence rules are yet to be finalized.

Reduced plugin dependencies

We removed our dependency on RichUI and a couple of other plugins, which were either not fully used yet by the CMS’s current features, or were providing unnecessary bloat.

In fact we don’t use any Grails plugins for JS-related UI work now, only the FCKEditor plugin for the rich editor for HTML editing.

Separation into Grails Plugin and Application

This was a bit of an upheaval what with all the refactoring going on too, but Weceem which was formally a Grails application is now 99% encapsulated in the Grails WeceemCMS plugin which you can install into your own Grails applications to instantly add a great extensible CMS with a ready to use admin interface.

The plugin is hosted in the central Grails plugin repository (eg: grails install-plugin weceem).

The other 1% of the original Weceem application functionality remains a standalone application that uses the Weceem CMS plugin and simply adds some config mechanisms for the DataSource, and adds Acegi security and a default content repository, a copy of the weceem.org site. Its literally a run-and-go CMS, the full source of which is under 250KB zipped!

The plugin has a very simple abstraction of security which may be subject to change in coming releases until we hit 1.0, but this allows the plugin to not care about what authentication and authorisation mechanisms you want to use. We simply abstracted this functionality into a service where you can inject your own handlers to obtain the currently logged in user id etc.

Navigation and extensible admin

More work remains to be done on this but we have utilized the Grails Navigation plugin for the admin menus, including the items in the Administration page.

What this means is that applications that use the Weceem CMS plugin can inject their own admin screens into the UI provided by Weceem. This is absolutely trivial to achieve with the navigation plugin, and exactly this approach is used by the Weceem application to add user management screens which are specific to the app, into the Administration screen:

class UserController {
  static navigation = [group:'weceem.app.admin',
    action: 'list', title: 'users']
...
}

Chowing down

Eating your own dog food is always recommended (who invented that phrase… who eats dog food anyway, I know I wouldn’t recommend it) and we do this in a big way:

1. Weceem.org is self hosted with Weceem CMS application
2. Weceem CMS application uses the Weceem CMS plugin, and proves that the abstractions work
3. The people that are developing Weceem are using it for real world sites other than weceem.org

Next up…

We’re already working on version 0.3 which should bring full blog functionality in, clean up some UI niggles and bugs and flesh out the Wiki functionality too – time permitting. Oh and more test coverage and functional tests. The gap to the next release has to be a lot shorter!

I’ve put together a quick screencast showing a quick run through the admin parts of Weceem from a developer perspective. You can download it here.

Grails 1.2M1 and why you need to download it NOW

Some of you may have noticed that I love Grails. You may also have noticed that I bitch about Grails bugs a lot too. You always hurt the ones you love.

Well I was chatting with Graeme the other day as I do like to moan about all the Grails bugs I find. I often joke that I seem to be a magnet for them.

Here’s the deal. Grails stands on the shoulders of giants: Spring, Hibernate, Groovy etc. These techs are really powerful but also complex. That is of course the beauty of Grails – it makes using these techs together so simple.

But here’s the rub. Both the Grails code and those libraries it uses will always have bugs, and sadly regressions are also inevitable. For me regressions are the real enemy – bugs in new features are not so bad, you can just make do without the new feature like you used to.

Why do regressions happen? Because there was no regression test for that code – test code coverage was too low for that use case.

Why aren’t there tests for the regression you just found? Because humans can’t second guess the complex high-level interactions that users of Grails create when they develop with it.

The Grails dev team cannot also write lots of complex applications to be used purely as test cases. There are more and more functional tests, but for true full stack regression testing you need to run new releases of Grails through proven non-trivial real-world applications.

Grails CI server already builds some test applications and runs their functional tests against Grails HEAD. Ideally I would love for some large open source / internal use applications to be “donated” (with high test coverage of their own!) to be run privately on Grails CI – a partnership that would involve developer assistance to the Grails team if the tests start failing.

However, back to the simpler solution for now.

Obviously I’m very passionate about quality of software. That’s why I’m going to beg everybody to download Grails 1.2M1 and run it with their existing apps and plugins locally, especially running all your own tests (you have lots of those, right?).

Then anything that has broken MUST be reported immediately and JIRA’d. It is either a – probably unintentional – breaking change or a regression that is not covered by a test.

Doing this and reporting any problems quickly is so important I cannot stress it enough.

Otherwise what happens is, come 1.2 release, you may suddenly find you can’t use it because of regressions and then we end up in a situation where nobody trusts the “first release” of any new version and you always have to wait for point releases to fix regressions.

That is no way to build confidence in the quality of a product.

Graeme et al gave us Grails to help us do our day jobs. Let’s make life easier for all of us and give back a little test time.

You’d only waste that time later when you try to use a new build and hit problems – and as seasoned developers know, those kinds of things often happen on important product launch days. Ouch.

Trust me – I’m groaning about it too. I have half a dozen plugins to test (with not enough test coverage in them) but if I don’t do it now I’ll only have to firefight it later when 1.2 comes out.

It is a great motivation to increase your own test coverage

Update: PS I forgot to mention. Sometimes, as is true currently, there are some unfixed bugs in underlying libraries like Hibernate. Sometimes the Grails Dev team can’t work around these – so once these problems are found in Grails they are then reported against the underlying library and we need users to request that the maintainers of that code fix the problem. Oh, even better users can submit patches to those maintainers. It’s Open Source after all.