Yes indeed, I don't provide an entry point for my lib-like module. However, there're handfull of other singletons one might have a necessity to have an access to (EventBus was just an example). E.g. com.google.gwt.core.client.Scheduler. Prior to GIN we had a sole option to obtain an instance by calling Scheduler.get(). Now I try to avoid mixing *GWT.create(), other static factories* and *@Inject *within client's code and therefore *prefer injection *anywhere possible. But here comes the same problem. Suppose, I *injected* the scheduler in some class within my lib-like module and intentionally left no binding within my lib config module. Now the client of my lib-like module either starts to get *"no binding found"* exceptions, or even worse - silently execute with new scheduler instances injected every time (if e.g. there was a default constructor for Scheduler).
On Wednesday, October 26, 2016 at 9:28:34 PM UTC+3, Jens wrote: > > Sounds like your visual components act as libraries, thus not having their > own GWT entry point. > > IMHO your visual components should not provide bindings for classes they > do not own. That means app wide singletons like an EventBus must be > provided by the app that includes the visual component. > > -- J. > -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
