Group items tagged

there's absolutely nothing in GWT proper related to MVP actually; I refuse to call Activities an "MVP framework", it has nothing to do with MVP in my opinion

try to disconnect activities from MVP: Activities don't force you to do MVP, and you'll use MVP beyond Activities.

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.

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.

It however clarify things about how Google sees MVP in GWT. They're even adding some MVP "framework" to GWT 2.1 (IsWidget and Activities, where an Activity is more or less your presenter, from what I understood).

RequestFactory on the other hand is a new thing for efficient CRUD operations on entity objects, which plugs more-or-less directly into the new Data widgets. Those widgets do blur the line a bit, but they're not really about presentation "logic", and they're somehow MVP- based themselves.

For your convenience, here is the net of it. With MVC, the model is thick with business rules and glue code to a data access layer. The view has lots of dependencies on the model. The controller is usually a framework component driven by some kind of configuration, usually XML based. With MVP, the model is lightweight POJOs. The view is mockable. It is the presenter that is heavy with glue code and business rules. The thinking here is that MVP is more suited for TDD than MVC. Another notable feature of MVP in GWT apps is the use of an event bus instead of hard coded event handler dependencies. Typically, that event bus is implemented as either the HandlerManager from GWT itself or the PropertyChangeSupport class from the GWTx library.

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.

An activity in GWT 2.1 is analogous to a presenter in MVP terminology. It contains no Widgets or UI code. Activities are started and stopped by an ActivityManager associated with a container Widget. A powerful new feature in GWT 2.1 is that an Activity can automatically display a warning confirmation when the Activity is about to be stopped (such as when the user navigates to a new Place). In addition, the ActivityManager warns the user before the window is about to be closed.

A place in GWT 2.1 is a Java object representing a particular state of the UI. A Place can be converted to and from a URL history token (see GWT's History object) by defining a PlaceTokenizer for each Place, and the PlaceHistoryHandler automatically updates the browser URL corresponding to each Place in your app.

A key concept of MVP development is that a view is defined by an interface.

I believe the reason we've not created View and Presenter interfaces to date is because there are two different styles of MVP widely in use, only one of which allows the view to call the presenter as in your example. Which leaves us in the funny position that the new MVP framework is missing *formal* definitions of View and Presenter. Personally, I think it's a good thing that GWT Activities and Places are independent of views and presenters so as not to force you into one model. I think View and Presenter as you've described would fall in the category of things that are not quite core code, but are nevertheless useful abstractions that probably need a home in the GWT source somewhere for reference. We'll chew on this a bit for 2.1.1...

from what it seems to me the GWT 2.1 MVP is quite different than GWTP (and from GWT-MVP), and is not targeted to the same audience. I would say it is targeted to developers who want to develop Spring-GWT applications in a Grails/RoR way.

MVP Framework The MVP Framework is an app framework that makes it easy for you to connect Data Presentation Widgets with backend data. Using this framework you create views that are focused on displaying data, Activities and an AcivityManager which are the "presenters", responsible for handling self-contained actions, and RequestFactories that fetch and propagate model changes throughout your app. To make developing apps of this style easier, the 1.1 M1 release of Spring Roo, can generate and maintain the boilerplate code associated with connecting your app's components with GWT's MVP Framework.

the data presentation widgets use a 'flyweight' design. Rather than being a container of other widgets, which can tend to be heavy, they build up chunks of HTML that is injected into the DOM. This not only speeds up initialization, but also reduces the event handling overhead that can slow down user experience when there are hundreds of widgets within a view.

To upgrade to 2.1 M1, simply do the following Download GWT 2.1 M1 from the download page and unpack it to the directory of your choice. If you use Eclipse to develop, you should also download the Google Plugin for Eclipse from the same download page. Update your GWT project build path to use the latest gwt-user.jar and gwt-dev.jar (and any other GWT jars that you included on your classpath). Replace references to gwt-dev-<platform>.jar with the location of the new gwt-dev.jar (there is no longer a platform specific suffix). Update any run configurations or application compile and shell scripts to include the latest JARs in the classpath (same JARs as mentioned in step 2). Run a GWT compilation over your project to generate the latest GWT application files for your project. Deploy the latest GWT application files to your web server.

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 MVP Framework is an app framework that makes it easy for you to connect Data Presentation Widgets with backend data. Using this framework you create views that are focused on displaying data, Activities and an ActivityManager which are the "presenters", responsible for handling self-contained actions, and RequestFactories that fetch and propagate model changes throughout your app. To make developing apps of this style easier, the 1.1 M1 release of Spring Roo, can generate and maintain the boilerplate code associated with connecting your app's components with GWT's MVP Framework.