GWT - MVP

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.

o summarize, here are some quotes: * It's extremely fast to build an initial scaffold (CRUD for all entities), but I'm not sure how easy it is to customize it for real world usage * When skimming the generated sources I saw A LOT of artifacts, which I don't feel comfortable with because it means that although "officially" my code is not coupled with Roo, if I were to drop it I would have to manage all these generated artifacts myself. * This expenses example is a nightmare to follow.  The bindings/ wiring  of all the pieces both client and server is nuts. * In M2, things have been cleaned up a bit

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.

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.

First, though, I think you shouldn't call it MVP. In my opinion it seems that what you're doing is MVC where the model is helped out by RPC. There is already so much variety in the meanings of this (MVP, MVC, etc...), especially with Activities and Request Factory coming into the picture that terminology is becoming important. Not because I don't know what you're describing, but because someone new to the frameworks will get thoroughly confused.

What is the best way to implement that ? 1) only one couple of presenter/view for object1 and this couple manages the display of object2 in each tab 2) one presenter/view object for object1 and one presenter/view for each instance of object2 ? in other words, do I have one couple of presenter/view by object model ?

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.

MVC implies that the server handles much of the view - with a GWT application the server is reduced to a glorified DAO. All you really need is integrate services from the backend into the frontend. What we really missing is something like RMI for the browser - GWT's RPC is as good as it gests for this purpose and and libraries like the GWT-SL allow you to directly publish Spring managed POJOs as services over RPC into the client.

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

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.