In gwt-platform (http://code.google.com/p/gwt-platform/) we use gin to
inject the EventBus to whoever needs it. The framework is designed
such that only the presenters communicate on it.

In your example, the gwt-platform way would be to create a
PresenterWidget for WidgetA and another for WidgetB. This way they act
like widgets, but have a nice testable Presenter layer that can be
used to decouple interactions via the EventBus. If your custom
presenter for WidgetA has too many of these "addClickHandler" methods,
you can break things down further, getting an entire hierarchy of
PresenterWidget.

Hope it helps,

   Philippe

On Jun 23, 5:13 pm, Paul Schwarz <paulsschw...@gmail.com> wrote:
> 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.
>
> On Jun 24, 2:18 am, Filipe Sousa <nat...@gmail.com> wrote:> I believe you can 
> use @UiField(provided=true):
>
> > @UiField(provided=true)  Foo foo
>
> > @Inject
> > UserDashboard(Foo foo) {
> >   this.foo = foo
>
> > }
>
> > On Jun 23, 10:03 pm, Paul Schwarz <paulsschw...@gmail.com> wrote:
>
> > > To answer my own question:
>
> > > 1. Gin can be used to inject the EventBus into the View as well as the
> > > Presenter, so now our View has a reference to the EventBus
>
> > > 2. In order to give the EventBus to the Widgets "owned" by the View
> > > those Widgets will require a constructor argument which will be the
> > > EventBus instance. UiBinder will fail if it doesn't find a default
> > > constructor, except that they have provided some nice work arounds.
> > > The appropriate workaround in this case is to provide a widget
> > > factory. Notice the use of @UiFactory in the example below:
>
> > > public class UserDashboard extends Composite {
> > >   interface MyUiBinder extends UiBinder<Widget, UserDashboard>;
> > >   private static final MyUiBinder uiBinder =
> > > GWT.create(MyUiBinder.class);
>
> > >   private final String[] teamNames;
>
> > >   public UserDashboard(String... teamNames) {
> > >     this.teamNames = teamNames;
> > >     initWidget(uiBinder.createAndBindUi(this));
> > >   }
>
> > >   /** Used by MyUiBinder to instantiate CricketScores */
> > >   @UiFactory CricketScores makeCricketScores() { // method name is
> > > insignificant
> > >     return new CricketScores(teamNames);
> > >   }
>
> > > }
>
> > > On Jun 23, 11:04 pm, Paul Schwarz <paulsschw...@gmail.com> wrote:
>
> > > > Working with the MVP pattern, or more like the VP pattern at this
> > > > point, I have:
> > > > MainPagePresenter
> > > > MainPageView
> > > > WidgetA
> > > > WidgetB
>
> > > > ... so imagine that WidgetA and WidgetB will be attached to
> > > > MainPageView.
>
> > > > Using Gin I have an EventBus injected into the MainPagePresenter. I
> > > > can then add click handlers that place an event on the EventBus from
> > > > within my MainPagePresenter. This might look like:
>
> > > > getMainPageView().getSendButton().addClickHandler(new ClickHandler(){
> > > >   public void onClick(ClickEvent event) {
> > > >     eventBus.fireEvent(new SendEvent());
> > > >   }
>
> > > > }
>
> > > > But now let's say that WidgetA and WidgetB actually have quite a few
> > > > user interactions, you'll end up with a lot of methods that look like
> > > > the one above sitting in your Presenter class.
> > > > 1. Is this correct?
> > > > Or
> > > > 2. should the Presenter hand the reference to the EventBus through to
> > > > its View, who may even hand it through to the Widgets so that they can
> > > > talk directly to the EventBus?
>
> > > > If the second option is the better option from an architecture/
> > > > separation of concerns point of view, then what is the best way to
> > > > hand the reference over to the View in such a way that keeps the
> > > > coupling between Presenter and View as loose as possible?
>
> > > > Note, currently my Presenter defines a View interface which my View
> > > > implements, so the coupling is loose but based upon this interface.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to