Hi Etienne.
On Aug 28, 1:00 am, Etienne Neveu <[email protected]> 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 [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
-~----------~----~----~----~------~----~------~--~---
