MVP pattern is, at least it looks like it is, becoming a standard way to implement client logic on GWT projects. It is definitely a pattern that brings order into client side of application. There is a model, consisted of data that needs to be presented to the user, and there is easily understandable relationship between UI (view) and logic responsible for that view (for specific part of UI). Furthermore, there is a clear boundary separating the responsibilities of view and presenter classes, which is not exactly the case in MVC approach. It is simple to understand which part of logic is used for smart things and operations and which only for presentation of data. This is clearly great benefit.
This pattern is used in conjunction with event bus mechanism on our project – every presenter class has EventBus instance injected and is capable to fire and listen to the events. This proved more than useful, especially in cases when is necessary to transfer a message from one presenter to another (or more others). Simply, every presenter interested in certain type of message needs to register appropriate event listener and it will be notified upon the firing of the event of that type. This was also easy to implement, since nowadays GWT provides a built-in mechanism for such a thing (HandlerManager). But be aware, there is a potential danger of piling up different types of these events and their listeners which would surely lead to serious issues in maintainability of the application. Basically, one has to know what is really needed to be registered through the event bus and what not. For example, events of UI components, such as onClick or onMouseOver, are usually events that shouldn’t be processed in that way. On the other hand, events that describe changed state of application, for example, are exactly what should be registered.
Another thing that eases the job is UI Binder – an option that speeds up development of view classes and makes it more natural. By using XML definitions (in which names of GWT widgets are XML tag names), UI Binder brings writing of UI closer to what web pages really are – HTML. But, combination of UI Binder and MVP pattern does have footprint too great. Beside data model classes, there has to be a presenter logic and separate view class – beside XML definition of the view, there has to be a .java view class – it all makes a sum of, at least, four files for each page or component. Every page that is more complex than really trivial, and at the same time has good modularity, will demand far more than these four files. I have doubts regarding this. On one hand, it’s a good thing to do this kind of modularization, but, on the other, there is a good chance that an explosion of code happens after some period of development. And what is the time needed for this phenomenon to happen? In our case, not very long. Maybe a two or three sprints – roughly, some time over two months of work.
Your job at codecentric?
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.