Group items tagged

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.

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

if your concern is testing your presenter, then how about changing your MVP from the "Passive View" pattern (the one showed by Ray Ryan at I/0 2009) to the "Supervising Controller" pattern (the one used by Cell widgets internally and by applications generated by Spring Roo): http://martinfowler.com/eaaDev/uiArchs.html Sure you test a bit less things as you leave more of the logic into the view than with a "Passive View", but in my experience it also makes tests much more easier to write and more readable, as you need far less mocks and stubs (no MockButton, MockTextBox, etc. only a MockView).

originally the MVP pattern was design for separating the view from its logic and the model it is displaying (as the MVC). Since the arriving of UIBinder I found the word View misused. Actually, strictly speaking the View is contained in the ui.xml file and the "Controller" is the corresponding java file which is implementing the corresponding logic and instanciation. This file merely represents a kind of Controller. The Presenter used in this tutorial is (for me) nothing more than a ControllerProvider which enable the ability to provide differents implementations of the view logic. What I'm founding strange is the fact that their are using the same acronym (MVP) for two differents approaches :  - first one was Presenter centered as the abstraction was done on Display and aggregation were done against the presenter  - second one was Display AND Presenter centered as the abstraction is done on Presenter and Display the both referencing each other. But this approach is mainly due to the fact that UIBinder is removing a lot of boiler plate code from event handling (and first MVP tutorial was not using it), but in the same way UIBinder tends people to adapt the original MVP pattern to be able to use all its power ! That why there is so much reflexion to mix UIBinder and MVP together.

Yeah, the one problem with UiBinder and MVP is this pattern collision.... UiBinder says, "view are directly attached to views". MVP says, "view's are attached to presenters, if you want to chain views the presenters control this". Consequently, you can't get UiBinder to create your @UiFields (i.e. empty constructor) and you can't get Gin to @Inject them into the view either... because they are in the presenter. Unless of course you use @Named+Singleton bindings in Gin and then both presenter and view will be injected with the same object. This is the one bit of boilerplate we're still writing.

I looked into that, and (unless I'm wrong), I think that @UiField(provided=true) will cause the UiBinder to look in the .ui.xml file for argument to satisfy Foo. In my case I am trying to "inject" an EventBus into the widget, not a visual element.

How I understand things, a display region is a dynamic part of a webpage; Depending on the place you're at, a display region is populated with a specific activity. A activity manager is the manager of a display region and decides the right activity to show up for a given display region when a certain page is showing. So, in terms of your question : a display region can be a dynamic menu, a sidebar, a logout/login link.... not the entire group. An example page with menu displayregion, maincontent displayregion, sidebar displayregion example page #ContactDetailsPage:FooBar +> sidebar display region will be instructed by the sidebar- activitymanager to start the activity GrandChildrenActivity (display grandchildren in side bar) +> maincontact display region will be instructed by the maincontentarea-activitymanager to start the activity ContactDetailsActivity (display contact details in main content area) +> menu display region will be instructed by the menu-activitymanager to start the activity MenuActivity (show the menu) example page #Login +> sidebar display region will be instructed by the sidebar- activitymanager to display nothing (NULL) +> maincontact display region will be instructed by the maincontentarea-activitymanager to start the activity LoginActivity (display login page) +> menu display region will be instructed by the menu-activitymanager to start the activity WelcomeActivity (show a welcome msg) etc etc.

places and activities are orthogonal to each other a webpage consists of many display regions every display region is managed by a activity manager when a place change occurs, the activity managers are notified and they decide the activity to live inside the display region

Actually HelloMVP is a really confusing example, because - the activities are called HelloActivity and GoodbyeActivity - the places are called HelloPlace and GoodbyePlace but the activities and places are orthogonal to each other. That doesn't help to get a clearer understanding.