what should be the role of Controller in gwt applications implementing MVP pattern?

I am new to GWT and getting back to programming after long gap...my question is about MVP implementation in GWT, I have gone through the following post and they were quite helpfull, but i still have some doubts

What are MVP and MVC and what is the difference? What's your recommendation for architecting GWT applications? MVC, MVP or custom messaging solution?

i 开发者_运维问答think the GWT tutorial (http://code.google.com/webtoolkit/articles/mvp-architecture.html) of MVP also has contoller (AppController ) in place and some of the responses are managed at Contoller level not at presenter. So my question is what should be the role of Controller in MVP pattern implementation?

From where should we initiate the async server call, presenter or controller , say if i have to save the record should i call the server function (which calls the DAO and saves the record) from Presenter or should presenter post event using event bus and conroller act on the event and calls server function for saving.

The GWT tutorial page you linked to says about the AppController:

To handle logic that is not specific to any presenter and instead resides at the application layer, we'll introduce the AppController component.

So it's the glue between multiple Presenters, Views and the Model (maybe multiple Models). It also handles the browser history. And maybe additional things that aren't specific to one presenter.

As for the server call: There are several options, but I personally wouldn't do it from the view, and also not from the presenter - I'd use a model listener. The reason is, that multiple views and presenters can work together on one model. And when they change the model, that change should be sent to the server. Maybe you don't want to do that immediately, but collect a few changes before you send them. In that case, you could have a timer that's set up - well - by the AppController.

Answering to your last paragraph, I would say you should do it in presenter if there is something (some button) on view that is supposed to do it. Presenter is logically strongly tied to view (technically it should be weakly tied, by interfaces only not by implementations). If you want to save the record on some action which is not explicitly called from view, I wouldn't do it in presenter.