Re: Deferred Binding, Gin in library/widget ?
I believe you would have to add @Inject annotations to your constructors. If you don't, developers using the framework can always hand-code a factory of some sort (Provider in Guice/GIN) to create instances (the factory gets dependencies injected into it so that it can inject them into the objects it creates). Also, if you don't want to add a dependency on Guice/GIN, you may be able to depend on on just javax.inject instead, though I'm not sure. It's worth looking, though, since having your library depend on GIN just got thornier with the release of GWT 2.2. Developers will have to pick a version of the GIN jar based on which version of GWT they're using. -Brian On Mon, Feb 28, 2011 at 3:24 AM, Uemit uemit.se...@gmail.com wrote: But in case I use a app-wide URL I still have to inject the URL into my DataSource class right? I could use Field Injection but isn't constructor injection the recommended way to do it ? I think it boils down to the question: What is the best practice if you want to develop a standalone library which doesn't care if the user uses DI or any other method to pass resources and dependencies into my library classes? Sorry that I repeat the question but do I have to annotate the constructor with @Inject if I want to allow for constructor based DI or is there any other way (to avoid dependency to the guice/gin in my library)? Thanks in advance 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deferred Binding, Gin in library/widget ?
But in case I use a app-wide URL I still have to inject the URL into my DataSource class right? I could use Field Injection but isn't constructor injection the recommended way to do it ? I think it boils down to the question: What is the best practice if you want to develop a standalone library which doesn't care if the user uses DI or any other method to pass resources and dependencies into my library classes? Sorry that I repeat the question but do I have to annotate the constructor with @Inject if I want to allow for constructor based DI or is there any other way (to avoid dependency to the guice/gin in my library)? Thanks in advance 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deferred Binding, Gin in library/widget ?
@Brian: I agree, after thinking a little bit more about that problem and taking your comments into account I think that deferred binding might not be really suitable for my use case. I also agree that the best approach is to set the datasource in the constructor thus enabling users to use Dependency injection if they want. But do I have to annotate the constructor with @Inject in order to allow for DI ? (because in that case I would create a dependency to gin and guice in my standalone library which i want to avoid). -- 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.
Re: Deferred Binding, Gin in library/widget ?
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.
Re: Deferred Binding, Gin in library/widget ?
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? The difference is that if you provide the url on an instance basis than your creation mechanism has to be aware of that url. In other words, all your DataSource-derived classes need to take a URL at creation time. (They could ignore it if they don't need it, but it's a code smell.) If the URL is an app-wide resource, then you can create both StandardDataSource and HttpDataSource without specifying a URL so they are effectively the same. If you have a limited number of URLs to different resources, an option might be to extend HttpDataSource with, say: TwitterDataSource FlickrDataSource ... These DataSource can then have a parameter-less constructor. Cheers, Philippe -- 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.
Re: Deferred Binding, Gin in library/widget ?
@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
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.se...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: Deferred Binding, Gin in library/widget ?
Hi Uemit,
I like your question and must say that I've personally run quite a few times
into the deferred binding vs injection question. My personal take on
this is that I always favor injection, unless the binding should be
property-dependent. By property-dependent I mean that the binding depends on
any of the deferred property defined in my .gwt.xml. Typically: browser or
language. The reason I prefer injection is because it's more powerful: it
allows for non-default constructor and will inject the newly created class.
When you really have to use deferred binding, I see three cases:
1) Your implementations have no dependencies.
This is the easy case. Just call GWT.create(BaseInterface.class), or @Inject
BaseInterface and rely on Gin calling GWT.create, and use replace-with as
you did.
2) Your implementations have dependencies that need to be @Inject-ed
It gets trickier and I have never done it. One approach I might use would be
to statically inject the ginjector in the abstract class and use it to fetch
dependencies. Alternatively, you could statically inject the dependencies
themselves (although in that case, if the dependencies are different for
each implementation, you will have to statically inject all the
implementations, even the ones you don't use, which is wasteful).
I think you fall exactly in this category: the url is probably an
application-wide resource that you want to inject into your HttpDataSource
(if it's not, I agree with Brian Reilly: your two DataSource have different
APIs and cannot be created interchangeably: when creating HttpDataSource the
user needs to specify a URL, not when creating other types of DataSource.)
3) Your implementation needs some per-instance parameters (i.e. they would
use a Gin assisted factory)
Here, the key is to perform the deferred binding on a factory instead of the
type itself. For example:
public interface FormattedDateFactory {
FormattedDate create(Date date);
}
public class EnglishFormattedDateFactory {
public FormattedDate create(Date date) {
return new EnglishFormattedDate(date);
}
}
public class ChineseFormattedDateFactory {
public FormattedDate create(Date date) {
return new ChineseFormattedDate(date);
}
}
replace-with class=EnglishFormattedDateFactory
when-type-is class=FormattedDateFactory /
/replace-with
replace-with class=ChineseFormattedDateFactory
when-type-is class=FormattedDateFactory /
when-property-is name=locale value=zh/
/replace-with
If you need to inject dependencies in your factories (or your FormatedDate
implementations) then you will need to use one of the trick of (2).
- - - - - - -
By the way, I'm working on much better way of mixing deferred binding and
dependency injection. If you're interested, star this issue in Gin:
http://code.google.com/p/google-gin/issues/detail?id=142
Hope it helps!
Philippe
--
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.
Re: Deferred Binding, Gin in library/widget ?
I don't think this is a case where I would think of using either deferred binding or GIN. The API you outlined should work as is for anyone who can write their own datasource. For users who can only provide a URL to the data, they can use your HttpDataSource or a more specific subclass of HttpDataSource that you provide. (However, at that point, maybe what you really want is a pre-built application that prompts the user for the URL to their data?) Also, when using the API, users will be able to have multiple instances of the widget that use different datasources in the same application. Deferred binding is typically used in cases where you would want to use reflection but can't since the JRE emulation layer in JavaScript doesn't support reflection. That doesn't seem to come into play in this case. It's unclear to me, though, how you want people to use your widget. Unless you're delivering a pre-built application, I think your java API is fine. If you are trying to deliver a pre-built application, deferred binding isn't going to help out because you'd have to supply your configuration parameters at compile time. -Brian On Mon, Feb 21, 2011 at 5:17 PM, Uemit uemit.se...@gmail.com wrote: Sorry for the thread bump: So I was thinking a little bit more about this problem. Both GIN and deferred binding respectively allow for customization of the widget's datasource during compile time. With gin I have a litte bit more flexibility (creating factory, singleton, etc)? For my personal taste the nicer/cleaner approach seems to be to use deferred binding to configure it. Is it actually possible to allow both? Configuration by either deferred binding or gin? And I still don't know how to solve the problem wiith the non-default constructor with either gin or deferred binding. In case of gin I might use a Factory but I am not sure if there is not a better approach. 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. -- 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.
Re: Deferred Binding, Gin in library/widget ?
Sorry for the thread bump: So I was thinking a little bit more about this problem. Both GIN and deferred binding respectively allow for customization of the widget's datasource during compile time. With gin I have a litte bit more flexibility (creating factory, singleton, etc)? For my personal taste the nicer/cleaner approach seems to be to use deferred binding to configure it. Is it actually possible to allow both? Configuration by either deferred binding or gin? And I still don't know how to solve the problem wiith the non-default constructor with either gin or deferred binding. In case of gin I might use a Factory but I am not sure if there is not a better approach. 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.
