akbertram/activityinfo — comment on commit d104480fe1f7c1210f954ce2c45d42ef76b3f194
File: sigmah/src/main/java/org/sigmah/client/page/report/ReportDesignPresenter.java line 24
By akbertram:

I appreciate the effort to seperate logic and UI, but my experience in the last two years with ActivitiyInfo and StatCloud9 is that the Presenter/View pattern often makes things worse, or at least doesn't help with complexity.

The problem that I see with this class is that division between logic and UI is entirely arbitrary: the presenter is adding UI components to a GXT layout, some events are being handled in the View, some in the presenter, it just ends up generating a lot of excess code for the interfaces and doesn't make the implementation any more clear.

In the future, let's try to avoid Presenter/View pattern *unless the logic is so complex that is necessary to write unit tests for verification* OR we need to reuse logic against several different kinds of views. An example fullfilling both criteria is AdminFieldSetPresenter.

By contrast, what would improve this code considerably is better decomposition. Recall the Single Responsability Principle: here you have a class that is doing ten different things: fetching a report preview, switch UI views, saving/loading models etc. Better to break up into several classes that have responsiblity for one of these things.