Group items tagged

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.

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.

In our app, in effect, each "parent presenter" also plays the role of "app controller"; but because we have the presenter/view dichotomy, the view exposes setSomeWidget(...) methods that the presenter calls; e.g. setHeader(...), setBody(...), setFooter(...).

> 3- what do you think of "presenter.go(container)" ? We do it the other way around: our presenters have a getView() method and the parent calls container.add((Widget) child.getView()). This is actually split between the presenter and the view, see above: view.setHeader(childPresenter.getView()) in the presenter, and containerWidget.add((Widget) child) in the view. The only "issue" with presenter.go(container) is that container must be a "simple" container, which means that when it's meant to be a dock (layout) panel, tab panel, or some other complex panel (or an absolute panel and you want to add with coordinates), you actually have to add a SimplePanel first and pass it as the "container" to the go() method. Otherwise, I can't see a problem with presenter.go(container).

navigation/ > history token inside multiple IF statements ? I'm using a very similar approach as the one in bikeshed: http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikes...

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.

you can separate your project into two modules: A module containing model and persistence code that is created by Spring Roo A GWT web application that you create by hand. Make the first (Roo) module a dependency of the second (GWT) module. Basically you're using Roo to create a JAR library that's used by your web application. As long as you don't run the controller command the Roo won't add any web application code to your module.

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.

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

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

Start moving the code of addStock to the view. Try not to use widget code on the presenter. Then create an interface and implement in the presenter: class SomeViewHandlers {     void deleteStock(Stock code); } You already have the deleteStock method... so just add "implements SomeViewHandlers" to it. Then you need to give to the display that interface (generally in the constructor): display.setViewHandlers(this); Then in the presenter lease the method as: private void addStock(JsArray<Stock> stocks) { display.addStock(stocks); } And in the view copyPaste the code of the method and change this:  removeButton.addClickHandler(new ClickHandler() {        @Override        public void onClick(ClickEvent event) {          *viewHandlers.*deleteStock(code);        }      });

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.

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.

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 ?

've started prototyping with Activities and can now give some more feedback on how it compares to my previous own implementation of a PlaceManager and how I used it with MVP.

The way I would do is to define a application event (eg. LocationEvent<LocationHandler>) & handler encapsulating whatever data (ex. co ordinates) that you need to send and fire the event. First presenter fires the event when the mouse is clicked. Second Presenter handles the event and takes appropriate action.