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 <[email protected]> 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 [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. > -- 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.
