Gwt architecture : why use MVP, Editors, RequestFactory, Gin etc?

Question

I've been working for a year now on a GWT application, and we never felt the need to use any of these frameworks or tools.

So i feel like we're probably missing out.

We do it "code behind" style.

Here's a simple example on how we build our code :

MyPanel.ui.xml :

<label ui:field="label"/>
<g:TextBox ui:field="box"/>
<g:Button ui:field="button"/>

MyPanel.java :

@UiField
LabelElement label;
@UiField
TextBox box;
@UiField
Button button;

MyBean myBean;

Messages messages = GWT.create(Messages.class);
MyServiceAsync myServiceAsync = GWT.create(MyService.class);

...


protected void i18n() {
  label.setInnerText(messages.label());
  button.setText(messages.button());
}

...

@UiHandler("box")
void box_onValueChange(ValueChangeEvent<String> event) {
  myBean.setText(event.getValue());
}

@UiHandler("button")
void button_onClick(ClickEvent event) {
  myServiceAsync.sendData(myBean, new AsyncCallback<MyResponse>() {
     @Override
     public void onSuccess(ReponseDispoBean result) {
       Window.alert(result.message());
     }

     @Override
     public void onFailure(Throwable caught) {
       Window.alert(caught.getMessage());
     }
  });
}

To communicate between panels (portions of pages, each in its own class), we use the widget's or the application's eventbus to send custom events.

To navigate we use the places/tokenizers/activities and the historymapper

And for unit and functionnal tests, we use gwt-test-utils

And that's it. So i'm wondering : what pain those tools help with ? What compelling reason is there to use them ?

Thanks

Answer 1

Editors and GIN deal with reducing boilerplate.
For instance, compare the same screen without and with Editors.
And when I say that GIN deals with reducing boilerplate, it's only if you already use dependency-injection (DI). If you don't use DI, then well, you probably should.

Similarly to DI, MVP helps with making testable code, particularly about testing the presentation logic (not necessarily the business logic, and not the UI). For instance, it doesn't really matter how you display something, what matters is that you display the right thing at the right time. One example would be errors: it doesn't really matter if they're in red at the top of the screen, or next the the form field, or in a tooltip on the form field which then turns red; what matters is that you send to the view the correct set of errors, at the right time. The how can be replaced or modified (and should ideally also be tested), but the what is the same.
MVP can also be great when building multi-factor apps: if the screens can be similar enough between mobile, tablet and desktop, then you can use the same presenter with 3 different views (and that's where DI shines!).

As for RequestFactory (RF), well, it's a different client-server protocol than GWT-RPC, with its own set of features and limitations. If you don't have an issue with GWT-RPC, you shouldn't switch (though I'd recommend you look at what RF is). To me, the major feature of RF is that it's a protocol (based on JSON) more than an API: the classes on the client and the server don't have to be exactly the same, provided they are compatible enough that the client and server understand each others (add a property, change an int to a double, etc.); this is a huge difference compared to GWT-RPC, where you'll have an error even for a very minor and subtle change in your classes.

But in the end, “if it ain't broke, don't fix it”.