For now I don't want to bring Gin or Guice into play because I want to
understand MVP. Then I will put DI to simplify things. Let's say I
have a basic UI with a north region and a center region of a
DockLayoutPanel. The north region contains a button, when clicking
that button, the center region is updated. I defined the button and
the main layout by using UIBinder.
<g:FlowPanel>
<g:Button ui:field="clickMeButton" />
</g:FlowPanel>
public class SimpleButtonWidget extends Composite implements
SimpleButtonPresenter.Display {
private static SimpleButtonWidgetUiBinder uiBinder =
GWT.create(SimpleButtonWidgetUiBinder.class);
interface SimpleButtonWidgetUiBinder extends
UiBinder<Widget, SimpleButtonWidget> {
}
@UiField
Button clickMeButton;
public SimpleButtonWidget() {
initWidget(uiBinder.createAndBindUi(this));
}
@Override
public Widget asWidget() {
return this;
}
@Override
public HasClickHandlers getButton() {
return clickMeButton;
}
}
<g:DockLayoutPanel><g:north size="45"><c:SimpleButtonWidget
ui:field="simpleButton"/></g:north>
</g:DockLayoutPanel>
public class MainAppContainer extends Composite implements
MainAppContainerPresenter.Display {
private static MainAppContainerUiBinder uiBinder =
GWT.create(MainAppContainerUiBinder.class);
interface MainAppContainerUiBinder extends
UiBinder<Widget, MainAppContainer> {
}
@UiField
SimpleButtonWidget simpleButton;
public MainAppContainer() {
initWidget(uiBinder.createAndBindUi(this));
}
@Override
public Widget asWidget() {
return this;
}
}
Now the presenters:
public class SimpleButtonPresenter implements Presenter {
public interface Display {
HasClickHandlers getButton();
Widget asWidget();
}
private final HandlerManager eventBus;
private final Display display;
public SimpleButtonPresenter(HandlerManager eventBus, Display
view) {
this.eventBus = eventBus;
this.display = view;
}
@Override
public void go(HasWidgets container) {
bind();
container.clear();
container.add(display.asWidget());
}
public void bind() {
System.out.println(display.getButton().addClickHandler(
new ClickHandler() {
@Override
public void onClick(ClickEvent event) {
System.out.println("Click");
}
}));
System.out.println("Click Registered");
}
}
public class MainAppContainerPresenter implements Presenter {
public interface Display {
Widget asWidget();
}
private final HandlerManager eventBus;
private final Display display;
private final SimpleButtonPresenter simpleButtonPresenter;
public MainAppContainerPresenter(HandlerManager eventBus, Display
view) {
this.eventBus = eventBus;
this.display = view;
simpleButtonPresenter = new SimpleButtonPresenter(eventBus,
new SimpleButtonWidget());
}
@Override
public void go(HasWidgets container) {
bind();
container.clear();
container.add(display.asWidget());
}
public void bind() {
simpleButtonPresenter.bind();
}
}
The App Controller:
presenter = new MainAppContainerPresenter(eventBus, new
MainAppContainer());
presenter.go(container);
When the MainAppContainerPresenter is created, a MainAppContainer is
passed which also creates a SimpleButtonWidget. Now inside the
constructor of MainAppContainerPresenter, I create a
SimpleButtonPresenter along with a SimpleButtonWidget. I am sure I am
doing something wrong because I guess I should only create one
SimpleButtonWidget and it should be linked to the
SimpleButtonPresenter.
When I click on the button I want to update the center region of the
DockLayoutPanel. In the click handler I will fire a custom event using
the event bus. Who should listen to that event, the presenter that
will have to update its content, in that case
MainAppContainerPresenter? In the presenter which captures that event,
how do I get a hold of a specific region of the DockLayoutPanel in the
Display interface?
I am sorry to ask so much questions but I struggle with the MVP
pattern.
On Feb 8, 2:28 pm, Joe Cheng <[email protected]> wrote:
> 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/19339...
>
>
>
> 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%2Bunsubs
> > [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.
