Some time ago I have used approach 2) and have bounded all ClientBundles as
Singletons. But now I would go with 1) because when you look at the
generated source code of a ClientBundle (use -gen <path> option) you will
see that nearly everything in a ClientBundle implementation is static. So it
doesn't really matter if its a Singleton or if you have several instances of
it flying around.
As of your other questions: Its definitly possible to bind ClientBundles in
a Singleton scope using .in(Singleton.class). As mentioned I have done this
before. But I think you have missunderstood the documentation. I think it
means: When you do not add any bind information for classes/interfaces that
are used with deferred binding then Gin will just do a GWT.create() which
obviously is not a singleton. But if you add bind information like
bind(...).in(Singleton.class) then GIN will of course create Singletons
because I think GIN will generate methods like:
YourClientBundle getCB() {
if(cb == null) {
cb = GWT.create(YourClientBundle.class);
}
return cb;
}
and uses this method to inject YourClientBundle into your classes.
-- J
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/ZomN2fK33yIJ.
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.
