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.

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.

Views A key concept of MVP development is that a view is defined by an interface. This allows multiple view implementations based on client characteristics (such as mobile vs. desktop) and also facilitates lightweight unit testing by avoiding the time-consuming GWTTestCase. There is no View interface or class in GWT which views must implement or extend; however, GWT 2.1 introduces an IsWidget interface that is implemented by most Widgets as well as Composite. It is useful for views to extend IsWidget if they do in fact provide a Widget. Here is a simple view from our sample app. public interface GoodbyeView extends IsWidget {    void setName(String goodbyeName);} The corresponding implementation extends Composite, which keeps dependencies on a particular Widget from leaking out. public class GoodbyeViewImpl extends Composite implements GoodbyeView {    SimplePanel viewPanel = new SimplePanel();    Element nameSpan = DOM.createSpan();    public GoodbyeViewImpl() {        viewPanel.getElement().appendChild(nameSpan);        initWidget(viewPanel);    }    @Override    public void setName(String name) {        nameSpan.setInnerText("Good-bye, " + name);    }}

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.

Place

Entity proxies simply extend the EntityProxy interface and use the @ProxyFor annotation to reference the server-side entity being represented. It is not necessary to represent every property and method from the server-side entity in the EntityProxy, only getters and setters for properties that should be exposed to the client. Note that while getId() is shown in this example, most client code will want to refer to EntityProxy.stableId() instead, as the EntityProxyId returned by this method is used throughout RequestFactory-related classes. Also note that the getSupervisor() method returns another proxy class (EmployeeProxy). All client-side code must reference EntityProxy subclasses. RequestFactory automatically converts proxy types to their corresponding entity types on the server.

How to navigate To navigate to a new Place in your application, call the goTo() method on your PlaceController. This is illustrated above in the goTo() method of HelloActivity. PlaceController warns the current Activity that it may be stopping (via a PlaceChangeRequest event) and once allowed, fires a PlaceChangeEvent with the new Place. The PlaceHistoryHandler listens for PlaceChangeEvents and updates the URL history token accordingly. The ActivityManager also listens for PlaceChangeEvents and uses your app's ActivityMapper to start the Activity associated with the new Place. Rather than using PlaceController.goTo(), you can also create a Hyperlink containing the history token for the new Place obtained by calling your PlaceHistoryMapper.getToken(). When the user navigates to a new URL (via hyperlink, back button, or bookmark), PlaceHistoryHandler catches the ValueChangeEvent from the History object and calls your app's PlaceHistoryMapper to turn the history token into its corresponding Place. It then calls PlaceController.goTo() with the new Place. What about apps with multiple panels in the same window whose state should all be saved together in a single URL? GWT 2.1 does not attempt to provide a generic implementation of a composite Place; however, your app could create a CompositePlace, CompositeActivity, and CompositePlace.Tokenizer classes that delegate to the constituent members. In this case, only the composite objects would need to be registered with your app's ActivityMapper and PlaceHistoryMapper.

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.

Clients of ValueStore subscribe to particular Properties of particular Ids, and values and validation errors are pushed into them asynchronously as they become available. Typically the code to set up these subscriptions is generated around UiBinder templates.

In a nutshell: RequestFactory is a scheme for referring to server side entities via Id and Property objects. It relies upon ValueStore, which is a more general system for dealing with data binding and client side validation in general.

PlaceHistoryHandler has been split into a concrete PlaceHistoryHandler and the PlaceHistoryMapper interface, which you're free to implement yourself or use as before, giving your sub-interface to GWT.create() so that it generates the implementation from the @WithTokenizers annotation (and/or factory if you're using PlaceHistoryMapperWithFactory); this approach is similar to the ActivityManager vs. ActivityMapper, with the added generator for the mapper based on PlaceTokenizers and @Prefix.

Activity.Display now is com.google.gwt.user.client.ui.AcceptsOneWidget, which is implemented by SimplePanel (showActivityWidget is thus renamed as setWidget). IsWidget has been moved to com.google.gwt.user.client.ui and is now implemented by Widget (which returns itself); this means that if your view classes extends Widget (most views extend it through Composite) you no longer have to implement the asWidget method. In addition, all widgets now accept IsWidget as argument where they already accepted Widget.