What is the IoC / “Springy” way to handle MVP in GWT? (Hint, probably not the Spring Roo 1.1 way)

Question

This is the Spring Roo 1.1 way of doing a factory that returns a GWT Activity (Yes, Spring Framework)

 public Activity getActivity(ProxyPlace place) {
    switch (place.getOperation()) {
      case DETAILS:
        return new EmployeeDetailsActivity((EntityProxyId<EmployeeProxy>)place.getProxyId(), requests, 
          placeController, ScaffoldApp.isMobile() ? EmployeeMobileDetailsView.instance() : EmployeeDetailsView.instance());

      case EDIT:
        return makeEditActivity(place);

      case CREATE:
        return makeCreateActivity();
    }

    throw new IllegalArgumentException("Unknown operation "
        + place.getOperation());
  }

It seems to me that we just went back hundred of years if we use a switch case with constants to make a factory. Now this is official auto generated Spring roo 1.1 with GWT / GAE integration, I kid you not

I can only assume this is some executives empty announcements because this is definitly not Spring

It seems VMWare and Google were too fast to get something out and didn't quite finish it, isn't it?

Am I missing something or this is half baked and by far not the way Spring + GWT MVP should work?

Do you have a better example of how Spring, GWT (2.1 MVP approach) and GAE should connect? I would hate to do all the plumbing of managing history and activities like this. (no annotations? IOC?)

I also would hate to reinvent the wheel and write my own Spring enhancement just to find someone else did the same, or worse, find out that SpringSource and Google will release roo 1.2 soon and make it right

Answer 1

I don't use Roo very much, so I can only guess. The code you cited looks basically like the corresponding part in the sample app from the "GWT MVP Development with Activities and Places" documentation page (Note: I didn't insert the comments, they're from the example code):

public class AppActivityMapper implements ActivityMapper {
...

 /**
  * Map each Place to its corresponding Activity. This would be a great use
  * for GIN.
  */
 @Override
 public Activity getActivity(Place place) {
    // This is begging for GIN
    if (place instanceof HelloPlace)
        return new HelloActivity((HelloPlace) place, clientFactory);
    else if (place instanceof GoodbyePlace)
        return new GoodbyeActivity((GoodbyePlace) place, clientFactory);

    return null;
 }
}

It doesn't matter much, if "switch + getOperation()" is used, or "if + instanceof". The problem is, that the Activity is built with a new operator. That conflicts with Dependency Injection basics.

So the basic thing to do with DI, is to inject factories into the ActivityMapper, one for each type of Place:

 public Activity getActivity(Place place) {
    if (place instanceof HelloPlace)
        return helloActivityFactory.build((HelloPlace) place);
    else if (place instanceof GoodbyePlace)
        return goodbyeActivityFactory.build((GoodbyePlace) place);

    return null;
 }

This still has the switching characteristic. That's because something must map between Places and Activities (the only alternative would be to inject an activity factory into each place). You could make the mapping configurable like this:

 Map<String, ActivityFactory> activityMap; /* injected */

 public Activity getActivity(Place place) {
    ActivityFactory factory = activityMap.get(place.getOperation());
    if (factory != null)
        return factory.build(place);

    return null;
 }

... if it's possible to define a generic ActivityFactory interface that works with common parameters (e.g. in my draft, build() would only use the place as an argument).

Now here's my guess (just a guess!), why something like this isn't in the Roo generated code: The "GWT MVP Development with Activities and Places" article is a follow-up to "Large scale application development and MVP", which presented MVP without DI, and promised to deliver a future "Using Gin to reduce code and facilitate testing" article. It's still not there, and the example code hasn't been updated to integrate Dependency Injection. I assume, that the Roo generated code is based to some degree on that article, because it's the reference on this topic.