Re: Deferred Binding, Gin in library/widget ?

It looks like gwt-log uses deferred binding for optimization to
eliminate any logging code that's lower than the configured logging
threshold. Personally, I would not use deferred binding for your use
case.

By accepting a datasource as a constructor parameter, you're set up
perfectly for dependency injection. How you (or the user of your
library) performs dependency injection is a separate decision.
Remember, dependency injection is just a technique, and GIN is a tool
to help use that technique. Whether you use GIN or Java to inject the
dependency, the choice of datasource is still made when writing the
application source code.

-Brian

On Thu, Feb 24, 2011 at 8:09 AM, Uemit <uemit.seren@gmail.com> wrote:
> @Brian
> I see your point but I am not entirely convinced yet that using either
> GIN/deferred binding might not be beneficial for my use case.
> Just for the record: I think it makes sense to allow the user to choose the
> specific datasource implementation at compile time, because once the
> datasource is set it isn't changed throughout the application (at least for
> an instance of my widget).
> Of course users of the widget/library should be able to implement their own
> datasources. But then again they can define it for a widget at compile time.
> I also plan to  provide say 3 different datasource implementations packaged
> with my library/widget.
> Of course it is possible to use setDataSource()  to set the datasource but
> isn't it nicer and easier to test if I use GIN to inject the DataSource ?
> Maybe deferred binding is probably too much overkill for that use case
> (tough it also used in the gwt-log library to configure different Loggers) ,
> especially if you might have different instances of that widget in your
> applications which might use different datasource implementations (deferred
> binding would only allow one type of datasource implementation).
> However using dependency injection might be a compromise. I could use
> annotations to inject different datasource implementations.
> Not sure if that makes sense.
> cheers
> Uemit
>
> --
> 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+unsubscribe@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-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.