@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.
