Group items tagged

There are a few things that you should keep in mind before you try to understand the MVP pattern    1. You don't have reflection or observer/observable pattern on the client    side.    2. Views depend on DOM and GWT UI Libraries, and are difficult to    mock/emulate in a pure java test case Now, to answer some of your questions

There are a few things that you should keep in mind before you try to understand the MVP pattern    1. You don't have reflection or observer/observable pattern on the client    side.    2. Views depend on DOM and GWT UI Libraries, and are difficult to    mock/emulate in a pure java test case Now, to answer some of your questions

The way I would do is to define a application event (eg. LocationEvent<LocationHandler>) & handler encapsulating whatever data (ex. co ordinates) that you need to send and fire the event. First presenter fires the event when the mouse is clicked. Second Presenter handles the event and takes appropriate action.

often your places are "parameterized", think of a detail/edit screen for example that needs the model's id. The token is a generic way to provide additional information (via the URL) to the place (i.e. the activity/-ies), i.e. "#editFoo:42". You can of course re-use one place to dispatch to several activities based on the token. See the (currently not used) for ProxyPlace and ProxyListPlace in the Expenses sample for an example.

In our app, in effect, each "parent presenter" also plays the role of "app controller"; but because we have the presenter/view dichotomy, the view exposes setSomeWidget(...) methods that the presenter calls; e.g. setHeader(...), setBody(...), setFooter(...).

> 3- what do you think of "presenter.go(container)" ? We do it the other way around: our presenters have a getView() method and the parent calls container.add((Widget) child.getView()). This is actually split between the presenter and the view, see above: view.setHeader(childPresenter.getView()) in the presenter, and containerWidget.add((Widget) child) in the view. The only "issue" with presenter.go(container) is that container must be a "simple" container, which means that when it's meant to be a dock (layout) panel, tab panel, or some other complex panel (or an absolute panel and you want to add with coordinates), you actually have to add a SimplePanel first and pass it as the "container" to the go() method. Otherwise, I can't see a problem with presenter.go(container).

navigation/ > history token inside multiple IF statements ? I'm using a very similar approach as the one in bikeshed: http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikes...

the MVP pattern has nothing in common with GWT's Place/History management framework (often referred to as GWT MVP). If you use GWT places/activities your app will gain bookmarkable urls that represent a place/application state and whenever such a url is visited a corresponding activity will be started. This activity is then responsible for attaching some UI/widgets to an area of your webpage. If this UI is complex and has user interaction elements then you could implement this UI with the MVP pattern to separate the UI from the logic that will be performed when the user interacts with this UI. And once you decide to use the MVP pattern then its in most cases easier to let the activity be the presenter. But its also possible to implement a separate presenter and let the activity hold a reference to it.