Hi Etienne. On Aug 28, 1:00 am, Etienne Neveu <nev...@gmail.com> wrote: > Hi Ricardo and Thomas, > > I don't know much about UIBinder (excepted that it seems promising and > that I'll have to look into it!), but I might have an idea regarding > the use of GIN / DI to improve upon Thomas' suggestion of: > "revers[ing] the dependency and hav[ing] StatsView instantiate its > StatsPresenter and keep a reference to it in a private field". > > I got this idea the other day while reading this semi-related google- > guice thread > :http://groups.google.com/group/google-guice/browse_thread/thread/2509... > . > > What about: > > - adding a provider method in your GinModule: > > @Provides > StatView provideStatView(StatPresenter statPresenter) { > return statPresenter.getView(); > > } > > - then injecting the view where you need it: > public MainView extends View { > > private final StatView statView; > > @Inject > public MainView(StatView statView) { > this.statView = statView; > } > > } > > When Gin creates the MainView, it looks a StatView to inject, sees > that it is provided by the @Provides method, creates and injects > dependencies into a new presenter (including a new view associated to > this presenter), and then returns the view. > You can then inject multiple StatViews in your UI, and they will each > create their associated presenter. > > If you want a singleton StatView, make the StatPresenter a singleton. > In this case, the @Provides method will create the presenter the first > time it is called, but will re-use this presenter (and associated > view) the following times. > You wouldn't even need to declare the StatView as a Singleton, because > its scope would be the same as the StatPresenter's scope, due to the > use of the @Provides method. > > In this case, your view would not have to instantiate your presenter / > keep a reference to it. Gin does the magic for you. Which is IMO good > for the separation of concerns. > > What do you think?
I gave this a try, it looks nice. But couldn't make it work, here's what i did. In my injector module: @Provides StatsView getStatsView(StatsPresenter presenter) { return (StatsView)presenter.getDisplay(); } In my StatsPresenter constructor: @Inject public StatsPresenter(final Display display, EventBus eventBus, final DispatchAsync dispatch) { It looks ok, but the Display in the StatsPresenter is a StatsView instance, so i additionally have in my injector module: bind(StatsPresenter.Display.class).to(StatsView.class); I get a StackOverflowError, which i'm thinking is due to a loop in the DI. Instantiating a StatsPresenter will trigger the need for a StatsPresenter.Display which is a StatsView, which then instantiates a StatsPresenter, ... just a guess but it looks like this. Did you give this a try yourself? Thanks, Ricardo > Regards, > Etienne --~--~---------~--~----~------------~-------~--~----~ 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-toolkit@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 -~----------~----~----~----~------~----~------~--~---