Thanks for your insight. I was wondering how the flat lookup approach would work. When the application starts the MainContainerPresenter would be created and the go method would be called with a RootLayoutPanel as a parameter. What I don't see is where the other presenters would be created, and how to wire up everything together. Also another topic I am experiencing problems is how to implement view transition. For instance a click on a button can modify part of the UI. I was thinking about using custom events (using the event bus) that presenters would listen to.
On Feb 7, 12:17 pm, Jesse Dowdle <[email protected]> wrote: > We have discussed this issue at length on our team, as we're building > an application that will eventually grow to be quite large. There are > certainly pros and cons to each approach (nesting presenters vs a flat > lookup at the AppController level). > > Nested Pros > Handy place to hook up a hierarchical location change framework > Chain of responsibility for loading data (parents can load data from > an rpc and pass it down to child presenters to ensure state is > maintained) > Easy re-use of groups of presenters, flexibility to mix and match. > Plays well with nested display objects, so if you've got a TabPanel, > each tab can be driven by a separate presenter and the panel itself > can have a presenter to load data common to all tabs. > > Nested Cons > Can be more difficult to analyze the layout of the application without > a single class where all presenter relationships are defined > Does not play well with view classes which have components that need > to be driven by multiple presenters. For example, if you have a ui.xml > with two main areas and you want a presenter to handle each, using > nested presenters requires more spaghetti code that just having a > couple of flat ones. > It can be more difficult to write unit tests against parent > presenters, because you have to take into account instantiation and > operation of child presenters... This can impact the complexity of the > mock objects you must create. > > Anyway, we've chosen to go with nested presenters, but I would say the > vote on our team for this was split 4/2, so clearly even for us not > everybody is in love with it. > > On Feb 5, 5:00 pm, Sydney <[email protected]> wrote: > > > > > I try to implement the best practices discussed in the article "Large > > scale application development and MVP". My application is designed > > using several widgets: > > MainContainerWidget: a DockLayoutPanel > > NorthWidget: a widget in the north region of the main container > > CenterWidget: a widget in the center region of the main container. > > This widget is a composite of two widget (TopWidget and BottomWidget) > > SouthWidget: a widget in the south region of the main container. > > > 1/ I created a Presenter for each widget. The CenterPresenter contains > > a TopPresenter and a BottomPresenter that are instanciated in the > > constructor of CenterPresenter. > > > public CenterPresenter(HandlerManager eventBus, Display display) { > > this.eventBus = eventBus; > > this.display = display; > > topPresenter = new TopPresenter(eventBus, new TopWidget()); > > bottomPresenter = new BottomPresenter(eventBus, new > > BottomWidget()); > > } > > > @Override > > public void go(HasWidgets container) { > > bind(); > > container.clear(); > > container.add(display.asWidget()); > > } > > > private void bind() { > > topPresenter.bind(); > > bottomPresenter.bind(); > > } > > > So basically when the CenterPresenter is created in the AppController > > class, it would create all its child presenters and call the bind > > methods. Does it seem a good approach or is there a better way? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
