GWT - MVP

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.

Ray Ryan - These posts are right on the money, Thomas. I think you hit the problem with this approach too: you still need nested Place objects, and those are a nuisance to make. E.g., in a master detail you might need to record both the page of the master list that is showing as well as which detail set. Maybe the thing to do is add a CompositePlace to GWT?Sep 14

Ray Ryan - The idea is that parents are an optical illusion. There is an activity that knows how to show lists of things. There is another that knows how to show details. In one arrangement of your app they may be on the screen at the same time. In another (*cough* mobile *cough*), they aren't. They really shouldn't know about each other.Sep 14

the key concept here is that an Activity can be a Presenter but a Presenter is not necessarily an activity.Oct 26DeleteUndo deleteReport spamNot spamRay Ryan - Exactly: not every presenter needs to bother being an activity.Oct

My application has several modules, and in each module, it may have different layout. Hence I have multiple level of Activity and in each module, I have an ActivityManager and ActivityMapper to create an appropriate Activity according to the Place or return null if not interested.  All the ActivityManagers are attached to a global Event bus.

The main issue in MVC is that these three elements are tighly bound together: the controller has to register to both the model and the view (and unregister if either changes), and when a view serves multiple controllers or a controller uses multiple models, that becomes quickly a mess.

MVP approach is more message-oriented. All messages (events) are fired on a single EventBus that is shared by all Presenters. Each presenter listens to events of interest, and fires new events according to actions. So a change in the in the EmployeeModel may be fired with an EmployeeModelChangedEvent, instead of attaching a listener to the model object. And we can easily create new Presenters that receive that same event and react accordingly.

The magnitude of such a shift is great: the model is no more the center and source of events (which would require special care in attaching and detaching to a specific instance), but it more a passive container of data, which may be copied, proxied, transformed, cached, without the GWT appliction any special care.Since the model is more a container of data ment for communication, I've highlighted the fact that it needs to be Serializable.

If you start thinking about the different kinds of viewers you can create you’ll see that most of them behave in the same way. Whether you display your list of boolean values (in this case) as a single select listbox (with one value being true at a time) or as a group of radio buttons or as a multiselect list (all selected are true) or as a group of check boxes the only thing separating the class ListBoxViewer from GroupViewer (for lack of a better name) would be what widgets they choose to use. They can both inherit SelectableListViewer which holds most of the logic and a setMultiSelect(boolean enabled) method. Later on when you want to create a table with a check box on each row that selects the row for some future action it’s just more of the same old.

So you have a ListBoxViewer that holds the listBox and has a getWidget() to give the widget to your panel.The viewer takes an instance of the interface ListBoxFormat in its constructor. The format implementation has a getValue(E element) that returns the value to display in the llistbox. The viewer has the required methods to set the values of the listbox and get a list of the currently selected values and so on. Probably along the way of what you’re planning to do next. By using viewers and formats you can do the same thing for other widgets like tables as well. So populating a table with values is as easy as tableViewer.setSource(aListOfTableRowObjects) where the objects in the list can by of any type that you can write a TableFormat for (with a getColumnValue(int column, E element) method). GlazedLists does this for the desktop (Swing and SWT/JFace). The cool thing there is that the viewer is aware of changes to the actual input list outside of the viewer, I don’t think that’s possible in GWT yet

the constructor uses an EnumTranslator to populate the labels in the ListBox. This allows you to use a standard GWT ConstantsWithLookup inteface to supply localized text for the enum values instead of the constant names. ConstantsWithLookup is just like Constants, but with the important ability to find a value dynamically without invoking a method corresponding to the property name.

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.

The kinds of changes to Activities and Places we're contemplating for future versions of GWT are primarily along the lines of using annotations and generators to automate the creation of PlaceTokenizers and ActivityMappers, for example. We're not talking about wholesale replacement, as we strive for API backward compatibility with each release.

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.

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.

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.

Databinding is about making two properties in sync. The target property could be a JPA entity, but also another widget property. From a Databinding framework perspective, a JPA entity object of any RPC interface should not be tied to the framework.

The intent is that ValueBox? would also be useful for data binding of plain old client side JavaBeans?, without any need for the Id and Property classes. I can define a ValueBox? interface tied to a set of bean classes and have it move their fields to and from HasValue? instances, enforcing validations in the process. I can set up this binding myself via calls like valueBox.setSubcription(bean, fieldNameString). Or I can GWT.create an EditorSupport? object to make those calls for me (which is why they didn't appear in the sketch).

Re: why re-invent a wheel, we want our new data backed widgets to play very nice in an asynchronous world — I'll tell you what values I want, you push them into me when they show up, and as they get updated. My impression of the existing frameworks is that they don't play naturally in that world.

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.

I really do not approach the different features of 2.1 as a whole "MVP" set of things: there's  - RequestFactory and ValueStore (I don't think ValueStore has any real use besides RequestFactory, though I'd be happy to be proved wrong) for a record-oriented client-server communication;  - Cell-based widgets for efficient data-backed lists, trees and tables  - PlaceController as typed layer over History (objects rather than strings, even though it's not yet plumbed to History, which at least proves it can be used without it)  - ActivityManager as an "application controller" (to use the term from the GWT tutorials) on top of PlaceController  - and on top of that, GWT provides some base activities plumbed with RequestFactory  - and finally, though it's not documented at all, EditorSupport which works with UiBinder in a view to generate "data-binding code" (as far as I understood) You're free to use any of them independently of the others.

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

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

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.

keeping History management abstracted in it’s own right

the need for Presenters to be capable of responding to History tokens

Presenters are decoupled from token managemen

how does the PlaceChange Event gets fired?? As of 2.1M2, PlaceController still isn't bound to History, so only PlaceController#goTo will fire first a PlaceChangeRequestedEvent (which can be rejected) and then (if the first hasn't been rejected by listeners) a PlaceChangeEvent.

he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1.

Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)

he generally adopted way of doing things in GWT is to have custom events go through the event bus. In this case, you're talking about "navigation", so maybe the concept of "place" would be better than "just" some custom event. I encourage you to look at gwt-platform, gwt- presenter and other MVP frameworks for GWT, and/or look at the Activity concept from the upcoming GWT 2.1. Using actvities, you'd have an ActivityManager managing your "center". The tree would use the PlaceController.goTo to navigate to a new "place". An ActivityMapper (that you passed to the ActivityManager in the constructor) would map the place to an Activity (a presenter), and the ActivityManager will manage the current Activity for the display it manages, i.e.it will stop() the current activity if its ok (willStop returns true) and then only start the new Activity, which will call the Display back to show its view. The tree would probably also listen to PlaceChangeEvent on the event bus to update the selected item depending on the current place (in case some other component calls the PlaceController.goTo)