Echo Web Framework

I was struck by Tod's comments regarding the pleasure of creating user interfaces in javascript, due to the terse manner in which an entire hierarchy of components can be created, and how easy that makes the code to read. I agree completely - it is particularly in the creation of UIs where this really helps, and vastly reduces the amount of code written, and the ability to look at code and visualise what it is doing.

Now there is no way I can code my app client-side, for reasons I won't discuss.

But - I still want these advantages.

So I got to thinking - what about other scripting languages that work server-side, such as Groovy.

It really didn't take me long to knock up an example, and here's my groovy source (fully working):

package org.sgodden.echo3.testapp.groovy;

import nextapp.echo.app.Button;
import nextapp.echo.app.Color;
import nextapp.echo.app.Extent;
import nextapp.echo.app.Grid;
import nextapp.echo.app.Label;

public class TestGrid extends Grid {

    public TestGrid() {
        size = 2;
        background = Color.BLUE;
        width = new Extent(100, Extent.PERCENT);
        components = [
            new Label(
                text: "Label 1"
            ),
            new Label(
                text: "Label 2"
            ),
            new Label(
                text: "Label 3"
            ),
            new Button(
                text: "Click me",
                actionPerformed: {evt -> println "You clicked me: $evt"}
            )
        ];
    }

}

I did have to make some very minor modifications to the server-side framework in order to allow this:

1. The getProperty / setProperty methods on Component had to be renamed, because they do not actually perform the work of true JavaBeans property mechanism hooks. They are used for altering the state of the local style (the component model), not the bean itself. So I renamed those to getComponentProperty / setComponentProperty. This was necessary because as groovy dynamically creates classes, it grafts on its own get/setProperty methods, to perform the work of standard JavaBeans property getting / setting. Without this change, it was not possible for Groovy classes to subclass Echo classes.
2. I had to add a setComponents(Component[]) method to Component, to allow children to be specified in one shot. The implementation of this method is trivial - it does removeAll, then just adds each component.

Look at that groovy code - I think it's beautiful. The economy of lines, the ability to visualise the tree you are creating from the hierarchical code, the trivial simplicity of adding the event listener. My devs are really happy about it - creating the UI is the most common and laborious task that they do, and with this approach they find it *much* easier. Additionally, we can put Groovy into "development" mode, where it does not cache the classes it generates, meaning they don't have to restart the server as they make UI changes. We believe our productivity and quality are about to improve significantly.

Tod, I hope you can see the power and benefit of this to those of us who need to stay server-side. I think there are *lots* of people that would want to use this. Would it be possible to incorporate those changes into the trunk? I appreciate that renaming the get/setProperty methods is a breaking change for anyone who has written their own component, but it's a simple refactor. Maybe it can wait for a point release.

Otherwise I will continue to apply patches to the trunk as I keep up with it.