Group items tagged

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.

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.

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.

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.

* I notice that you're injecting instances of your activities into your activity mapper. Activities are meant to be fairly lightweight objects, as opposed to the views that represent them, so they don't need to be singletons (which they effectively are since you have a single app with a single injected activity mapper). It's probably not necessarily a problem unless your activities have state associated with them (such as the entity that the user is currently working with), which you have to be careful to clear out between uses with different data. The same can be said about places.

My understanding is that you only want a single area of the shell to be managed by one ActivityManager. So if you have an entire shell/layout with more than one area that changes, let's say a main content area as well as a context menu (If I have MainAppPlace and SettingsAppPlace and OtherAppPlace both of which extend MainAppPlace, and you want to show a different context menu for Place of type SettingsAppPlace and places of type OtherAppPlace) I would just have main Shell that has a SimplePanel for content and Simplepanel for context_menu I just use an ActivityManager to control one spot of the main layout. is this not right? do you want your activitymanager controlling more than one area??