DDevelopment & Design

Passive view for Ext GWT applications

Seeing “Google Web Toolkit Architecture: Best Practices For Architecting Your GWT App” presentation by Ray Ryan coincided with the start of a new project – an Ext GWT front-end application for one of our clients. We liked the idea of testing front-end code entirely in JRE so we decided to give the model view presenter approach to building front-ends a try. Unfortunately, GXT widgets come with no fine-grained interfaces like GWT’s HasValue. Our display interfaces quickly ended up returning GXT widgets – hard to mock or even not possible to instantiate in JRE due to JSNI. We had to come up with a solution and do it fast. Technical debt had been registered on the project backlog and in a couple of days we had an opportunity to work on this. We developed several simple interfaces that let us compose display interfaces using this common vocabulary and factory class that returns implementations for standard GXT widgets. It is good to think about returned implementations as gateways that provide simple API whose implementation can be easily substituted by some test double. It’s better to look at some actual code, this should make everything more clear. The first of the interfaces is HasValue:

public interface HasValue {
    T getValue();
    void setValue(T value);
}

we have others – for selection, clicking, double clicking …

public interface HasSelected {
    public static interface Handler {
        void onSelected();
    }
    public void addHandler(Handler h);
}

Corresponding factory methods …

public static HasValue createHasValue(final Label label) {
    return new HasValue() {
        @Override
        public void setValue(String value) {
            label.setText(value);
        }

        @Override
        public String getValue() {
            return label.getText();
        }
    };
}
public static HasSelected createHasSelected(final Button button) {
    return new HasSelected() {

        @Override
        public void addHandler(final Handler handler) {
            button.addSelectionListener(new SelectionListener() {

                @Override
                public void componentSelected(ButtonEvent ce) {
                    handler.onSelected();
                }
            });
        }
    };
}

Now it is easy to build Display interfaces:

public class MyPresenter {

    public static interface Display {

        HasSelected getMyButtonSelected();

        HasValue getName();
    }

...
}

and their implementations:

public HasSelected getMyButtonSelected() {
    return DisplayMemberFactory.createHasSelected(myButton);
}

Simple.

— Previous article

How fast is TDD exactly?

Next article —

Eclipse ecosystem

You May Also Like
DDevelopment & Design

Spring Security by example: securing methods

This is a part of a simple Spring Security tutorial:

1. Set up and form authentication
2. User in the backend (getting logged user, authentication, testing)
3. Securing web resources
4. Securing methods
5. OpenID (login via gmail)
6. OAuth2 (login via Facebook)
7. Writing on Facebook wall with Spring Social

Securing web resources is all nice and cool, but in a well designed application it's more natural to secure methods (for example on backend facade or even domain objects). While we may get away with role-based authorization in many intranet business applications, nobody will ever handle assigning roles to users in a public, free to use Internet service. We need authorization based on rules described in our domain.

For example: there is a service AlterStory, that allows cooperative writing of stories, where one user is a director (like a movie director), deciding which chapter proposed by other authors should make it to the final story.

The method for accepting chapters, looks like this:

Read more »
DDevelopment & Design

Grails render as JSON catch

One of a reasons your controller doesn't render a proper response in JSON format might be wrong package name that you use. It is easy to overlook. Import are on top of a file, you look at your code and everything seems to be fine. Except response is still not in JSON format.

Consider this simple controller:

class RestJsonCatchController {
def grailsJson() {
render([first: 'foo', second: 5] as grails.converters.JSON)
    }

def netSfJson() {
render([first: 'foo', second: 5] as net.sf.json.JSON)
    }
}

And now, with finger crossed... We have a winner!

$ curl localhost:8080/example/restJsonCatch/grailsJson
{"first":"foo","second":5}
$ curl localhost:8080/example/restJsonCatch/netSfJson
{first=foo, second=5}

As you can see only grails.converters.JSON converts your response to JSON format. There is no such converter for net.sf.json.JSON, so Grails has no converter to apply and it renders Map normally.

Conclusion: always carefully look at your imports if you're working with JSON in Grails!

Edit: Burt suggested that this is a bug. I've submitted JIRA issue here: GRAILS-9622 render as class that is not a codec should throw exception