Group items tagged

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)

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

there is a clear distinction between *what the browser needs* (DTO) and *what the business needs* (domain objects). When you send JDO objects across the wire, you are sending your domain model. Its not what the browser wants, and that is a problem. Soon, you will have a presentational information in your domain model, and you will have restricted information being sent to the browser, and it will be a big mess. So, take a step back, and separate Domain objects from Presentation objects (or DTOs). Make your RPCs revolve around a particular view, and send all necessary information for that view in one RPC call. Note that now your Person would include company name and company id, but not the entire company object. Now, when the user clicks the company in the view, you make a RPC call to get company information (because you have company id). That's it. Works nicely, without having to make multiple calls.

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.

use the history and pass the information as parameters in the history token.

has a number of advantages provided the parameter is serializable (and small enough). For example, it could let the user bookmark the detail page of "Lady_Gaga". A bit trickier when the presenter is a dialog box, but totally doable.

Have a look at the Cell widgets' internals, they use MVP internally so the presenter can be tested independently from the views.

if your concern is testing your presenter, then how about changing your MVP from the "Passive View" pattern (the one showed by Ray Ryan at I/0 2009) to the "Supervising Controller" pattern (the one used by Cell widgets internally and by applications generated by Spring Roo): http://martinfowler.com/eaaDev/uiArchs.html Sure you test a bit less things as you leave more of the logic into the view than with a "Passive View", but in my experience it also makes tests much more easier to write and more readable, as you need far less mocks and stubs (no MockButton, MockTextBox, etc. only a MockView).

For your convenience, here is the net of it. With MVC, the model is thick with business rules and glue code to a data access layer. The view has lots of dependencies on the model. The controller is usually a framework component driven by some kind of configuration, usually XML based. With MVP, the model is lightweight POJOs. The view is mockable. It is the presenter that is heavy with glue code and business rules. The thinking here is that MVP is more suited for TDD than MVC. Another notable feature of MVP in GWT apps is the use of an event bus instead of hard coded event handler dependencies. Typically, that event bus is implemented as either the HandlerManager from GWT itself or the PropertyChangeSupport class from the GWTx library.