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...

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.

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.

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

> 2- when google wants to address problem of Nested/Layered presenters ? > header/body/footer, and body having its own dockpanellayout structure. We use the technique described in part II. Composite views are responsible for instantiating their own children, and making them available for the parallel composite presenters.

If you're referring to the ColumnDefinitions, we know they'll scale. One, it requires minimal widget overhead and is fast. No more embedding hundreds of widgets within a table. Two, it's extensible, and testable. As your model grows, your ColumnDefinitions grow, not your views.  ColumnDefinitions are quite trivial, the bulk of the code dedicated to generating HTML, and don't require a GwtTestCase.

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.

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.

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.