>
> I think the scheme I sketched gets around this issue. Gin isn't aware of
> any of the generated code. Rather, the generated code is aware of the public
> Ginjector interface. When Gin is asked to inject a MyUiBinder, it's just
> going to write GWT.create(MyUiBinder), and then call that instance's
> setFactory() method with itself. So this code:
>
> @Inject
> public MyWidget(MyUiBinder binder) extends Composite {
>
> public interface MyUiBinder extends UiBinderWithFactory<Widget, MyWidget,
> MyGinjector> {
> @Inject setFactory(MyGinjector factory);
> }
> }
>
>
> makes Gin generate the moral equivalent of
>
> new
> MyWidget((MyUiBinder.class) GWT.create(MyUiBinder.class)).setFactory(this);
>
>
Yes, this should work. It requires some boilerplate on the ginjector (which
often contains just a single method) but it has the advantage of not
requiring any additional infrastructure.
> Also, while I was assuming that for the most part the binder would be
> working off of the Ye One True Ginjector, there is no actual requirement
> that you do so, nor that your Factory be Ginjector at al. E.g.:
>
> @Inject
> public MyWidget(MyUiBinder binder) extends Composite {
>
> public static class Factory {
> @Inject @MagicScope EventBus eventBus;
>
> FooWidget makeAFoo() {
> return new Foo(eventBus);
> }
> }
>
> public interface MyUiBinder extends UiBinderWithFactory<Widget, MyWidget,
> MyGinjector> {
> @Inject setFactory(Factory factory);
> }
> }
>
>
No problem - this factory is essentially a provider, although in the usual
case it will have more than one creator method? You can also abuse assisted
inject here to have Gin generate the implementation for the factory
interface (assisted inject won't complain if you don't pass any local
variables :).
> And if it's possible for one Ginjector to create another (haven't been
> paying attention, sorry), that boilerplate could perhaps be even less?
>
> @Inject
> public MyWidget(MyUiBinder binder) extends Composite {
>
> @MagicScope
> public interface Factory extends Ginjector {
> EventBus eventBus;
> }
>
> public interface MyUiBinder extends UiBinderWithFactory<Widget, MyWidget,
> MyGinjector> {
> @Inject setFactory(Factory factory);
> }
> }
>
>
While this works in theory, you probably want a new ginjector that actually
inherits the injection framework of the original ginjector - otherwise it
won't have any of the bindings. Probably easier to use assisted inject as
outlined above.
> I think what we want is a class generated by UiBinder that has @Inject
>> annotated constructor/fields/methods for its required children and is then
>> used as input by the Gin generator to wire the injection up. But to
>> accomplish that, we'll need to fix the issue mentioned above.
>>
>> How does this sound?
>>
>
> Like it would need a lot more thought and a lot more work :-). (Although
> it's a nicely DI-framework-agnostic notion, now that the annotations live in
> javax.). We really wouldn't just want limit you to putting @Inject on
> everything, you'd want the full gin experience — e.g. to be allowed to put
> other annotations on specific fields, right? All of a sudden we have to
> provide an annotation syntax for ui.xml.
>
> Don't get me wrong, I would rather fix GWT.create() so that Ginjector
> actually could efficiently provide a getInstance(...) method, and to allow
> gin to see generated code. But those two conversations never seem to
> terminate, and I don't have the chops to just do them myself. So my question
> is: if we accept the current limitations, would this change be a worthwhile
> incremental step?
>
Yes, we should do the simple solution first. I'd really like to fix the
generator interaction challenge though, it would solve tons of other
problems as well.
>
>> Peter
>>
>>
>>
>>
>>> > public interface UiBinderWithFactory<U, O, F> extends UiBinder<U, O> {
>>> > /**
>>> > * Sets a factory to use when instantiating objects that are not
>>> > * provided via @UiFactory methods or @UiField(provided = true)
>>> fields.
>>> > * <p>
>>> > * When an instance is needed, a zero args method with an appropriate
>>> > return type
>>> > * will be sought on the factory to provide it. If none is found
>>> > GWT.create()
>>> > * will be used instead.
>>> > * <p>
>>> > * It is a compile time error for the factory to provide ambiguous
>>> > methods.
>>> > */
>>> > setFactory(F factory);
>>> > }
>>> >
>>> > You might wind up with code like…
>>> >
>>> > @Inject
>>> > public MyWidget(MyUiBinder binder) extends Composite {
>>> >
>>> > public interface MyUiBinder extends UiBinderWithFactory<Widget,
>>> MyWidget,
>>> > MyGinjector> {
>>> > @Inject setFactory(MyGinjector factory);
>>> > }
>>> >
>>> > …and a few extra getters on your Ginjector.
>>> >
>>> > Now injecting an injector is generally a terrible idea, but it's
>>> something
>>> > at least. (Does that even work in Gin? And can you put @Inject on an
>>> > interface method?)
>>> > What do you think?
>>> > rjrjr
>>> >
>>> > --
>>> > http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "google-gin" group.
>>> To post to this group, send email to google-...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> google-gin+unsubscr...@googlegroups.com<google-gin%2bunsubscr...@googlegroups.com>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-gin?hl=en.
>>>
>>>
>> --
>> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-gin" group.
> To post to this group, send email to google-...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-gin+unsubscr...@googlegroups.com<google-gin%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-gin?hl=en.
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
