Thank you all for the good advice. I am glad I posted the question!
You convinced me going the DI route. I will try with and without GIN.
I will let you know or post an follow-up question :)
(not this week).
Regards,
Ronald
On Jan 26, 10:03 am, Jan Ehrhardt <jan.ehrha...@googlemail.com> wrote:
> Hi Ronald,
>
> I would recommend to ways:
>
> You should configure two GIN modules. One for authorization type A and one
> for B. This will allow you to configure the dependency in different ways.
> The authorization type will become a global property of your application. In
> your EntryPoint, you could have something like this:
>
> switch(authorization) {
> case A:
> ginjectorA.getPresenter(); // will create a presenter and its dependent
> view for auth type A
> case B:
> ginjectorB.getPresenter(); // will create a presenter and its dependent
> view for auth type B
>
> }
>
> You should always recognize that each 'Ginjector' is a couple of
> configurations. It could look like this:
>
> @GinModules({ModuleA.class})
> public interface GinjectorA extend Ginjector {
>
> Presenter getPresenter()
>
> }
>
> @GinModules({ModuleB.class})
> public interface GinjectorB extend Ginjector {
>
> Presenter getPresenter()
>
> }
>
> So your ModuleA's configure method can look like this:
>
> public void configure() {
> bind(Presenter.class).to(MyPresenter.class);
> bind(View.class).to(ViewA.class);
>
> }
>
> ModuleB looks similar.
> The benefit of this solution is, that you can do the same for other views
> and dependencies too. You've got just one point where the global information
> of the authorization type comes in.
>
> The second way would be to create a provider that does the job. Your
> presenter gets a dependency to the provider and the provider's 'get' method
> does the check. A provider is similar to a factory, but it isn't one.
>
> The idea of DI is to keep your code clean and in both cases it is done.
>
> Regards
> Jan Ehrhardt
>
>
>
> On Mon, Jan 25, 2010 at 6:15 PM, rmuller <rmul...@xiam.nl> wrote:
> > Hi Jan.
>
> > Guess what .. I am reading "Dependency Injection" (Dhanji R. Prasanna)
> > at this moment :)
> > So this was one of the things why I doubt my design. But I really do
> > not understand how DI (GIN) should
> > be applied in my case:
> > - A Presenter uses several Views. The view depends on the
> > authorization (implemented as enum). Now I do something like:
>
> > switch (authorization) {
> > case A:
> > view = new View(fieldSpecA);
> > break;
> > case B:
> > // etc
>
> > }
>
> > Regards,
> > Ronald
>
> > On 25 jan, 17:18, Jan Ehrhardt <jan.ehrha...@googlemail.com> wrote:
> > > The reason, why another class creats both and than puts the view into the
> > > presenter is called Dependency Injection. It is a widely used pattern,
> > that
> > > means that you should inject dependencies into classes instead of using
> > > factories or doing something like 'new DependentClass()' in the
> > constructor.
> > > In the best case, your presenter refers to a view interface and gets its
> > > view implementation injected.
>
> > > The easiest way of doing Dependency Injection in GWT is GIN (
> >http://code.google.com/p/google-gin). It allows you to configure
> > > dependencies and let GIN do the creation of objects and put one into
> > another
> > > at runtime.
>
> > > Dependency Inection is one of the best practices in GWT (and Java too)
> > > development (http://www.youtube.com/watch?v=PDuhR18-EdM)
>
> > > Regards
> > > Jan Ehrhardt
>
> > > On Mon, Jan 25, 2010 at 2:54 PM, rmuller <rmul...@xiam.nl> wrote:
> > > > Should not the Presenter create the view?
> > > > Sometimes you need different views (based on authorization data in my
> > > > case) where you can reuse the Presenter. I let the Presenter decide
> > > > which view to use. I do this in the ctor.
> > > > In all examples I see however, the Presenter and View are created by
> > > > the parent Presenter/AppContext. Also every View has its own Presenter
> > > > (1 : 1). So I wonder if my design is correct.
>
> > > > What is the general opinion about this?
>
> > > > Ronald
>
> > > > --
> > > > 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<google-web-toolkit%2Bunsubs
> > > > cr...@googlegroups.com><google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > > > .
> > > > 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 google-web-tool...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > .
> > 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 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.
