On my project I used Gin to wire up nested presenters/views, it is very nice. I wouldn't dream of doing large-scale MVP now without dependency injection--it really takes a lot of tedious wiring code out. This book helped a lot for me: http://www.amazon.com/Dependency-Injection-Dhanji-R-Prasanna/dp/193398855X
On Mon, Feb 8, 2010 at 10:55 AM, Sydney <[email protected]> wrote: > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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.
