Hi Phillipe Thanks for the interesting comments. I am still trying to fully understand dependency injection and sometimes I am not sure that I have ;-) I agree that dependency injection is more powerful and flexible compared to deferred binding.
So the three cases you described apply when I want to mix deferred binding with DI? After thinking a little bit about my problem and taking Biran's previous comments into account I decided against deferred binding and for designing the API so it can be used with DI (dependency injection). I haven't really decided whether the url is going to be an application wide resources or if it can be set to different values on an instance base. But does it really make a difference in regards to DI? In both cases I would try to inject the URL as a constructor injection? (I could use annotated dependency injection for different URLs in the app I guess?) The HttpDataSource class is a special implementation of the DataSouce and doesn't necessary mix with different datasource implementations. For example I might add a HTML5 LocalStoreDataSource which doesn't need an URL ressources but might take something else in the constructor. In your opinion what is the best DI setup for this use-case? And do I have to annotate my DataSource constructors with @Inject if I want to enable DI? This would create a dependency to GIN/GUICE in my library which I want to avoid. thanks in advance 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
