Getting rid of GWT MVP boilerplate

Question

Following the documentation on places & activities + MVP, for each page I have to create:

• a place
• an activity
• a tokenizer (I have to implement the tokenizing logic)
• an interface for the presenter (the activity implements this interface)
• an interface for the view
• the view implementation
• the ui binder xml for view implementation
• a node in app activity mapper
• a node in gin module for binding view interface to view implementation

I created an app with basic functionality(5 pages and a navbar) and I already have more than 1500 lines of code and ~40 files. I think this is completely unmaintainable, however I haven't found anything on solving this. There are a couple of frameworks(eg GWTP) which implement MVP but they need the same amount of boilerplate as well.

I could achieve the same functionality in ~200 lines using spring mvc or play.

What am I doing wrong and how would you solve it?

Answer 1

I think this is completely unmaintainable

I do not agree with you. Large number of small files is much better for maintenance than couple large files. I agree that GWT is much more verbose than Spring MVC:

• You do not need all these interfaces because of dynamic nature of JSP
• JSP in Sppring MVC case is not strictly typed and give your abilities to do many low level things automatically (for example data binding).
• And do not do some things at all (no need to clean up view between requests, view is stateless).

In a case of GWT due to strict nature of Java and statefull view you must do a lot of additional work. It is completely maintenable (if it is done correctly). Main advantage is that you can add unit tests for your presentation layer. Due to this fact it will be more maintenable for long running projects with complex UI, large codebase and big team. If it is not the case for you project (screens are simple and you do not plan to add unit tests for UI layer) then it may be better to:

• use some another more lightweight presentation technology (Spring MVC for example).
• or simplify your policy (for example allow presenter -> view interactions without interfaces). Normally you lose ability to unit test your presenters in this case. As mentioned by @Andrea Boscolo you can use GwtMockito as a workaround for this problem!

Two another advantages of interfaces between view and presenters:

• You can easy switch view implementation (famous case about making desctop UI -> mobile UI switch that unfortunately I never saw implemented)
• For me it is some kind of barrier that help keep presentation logic in presenter. Presenter know only about necessary things. I like this concept. This helps me write all pieces in right places.

What is really annoing with all these files is that it takes much time to setup one activity. To simplify it:

• Ensure that you use UiBinder template in eclipse
• Even more, you can write your code generator that will take activity name and package as parameters and then it will generate all necessary things. So you need just modify ActivityMapper and start writing important UI logic. It is done for my current project and makes me happy.

Another source of boilerplate is data binding. Consider using editor framework.

Answer 2

The main benefit of using MVP with GWT, is the ability to unit test your presenters in isolation, using plain JUnit TestCase, instead relying on the painfully slow GwtTestCase.

The other benefits, such as mainteinability, can be achieved using simpler project structures like @Maksym Demidas pointed out.

So the real question is if you want/need that degree of testing inside your project, at the cost of the aforementioned boilerplate. Do note that places and activities have nothing to do with MVP: you can use them to achieve MVP but they are simply about navigation and view transitions between places (URLs).

I'd really suggest you to take a look at the recent Erik Kuefler's Google IO 2013 presentation - Demystifying MVP and EventBus in GWT. It should help you identifying when to use MVP and when not. Also, take a look the at the open source library he released, specifically to GwtMockito (i.e., testing widget's logic in plain JUnit TestCase).