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.
