Instantiating injected classes from GWT generated code
PhilBeaudoin
I regularly need to instantiate injected classes from my code produced
via GWT generators. For example, my recent patch to support gin-
injected widgets in UiBinder code requires this. [1]
For the moment, the only option I have found is for the generated
class to grab the global ginjector and use it to instantiate the
class. This, however, requires the user to add a method in the
ginjector returning the desired type. This extra burden of adding a
method there is very tedious and does not keep change local.
Now, this would be solved if GIN supported Guice-like accessors in the
ginjector, as proposed in issue 89 [2]. However, as discussed by
aragos in this issue, it is not desirable in GIN because it would
force-compile a lot of classes that might not be needed. (All classes
if you take into account JIT binding and GWT.create instantiations.)
I have come up with a different proposal that would allow me to
elegantly solve the problem of instantiating injected classes in
generators without polluting the compiled code. What I propose is to
allow the ginjector to contain methods taking a single Annotation
parameter. For example:
Payment getPayment(Annotation annotation);
AsyncProvider<Payment> getPaymentAsyncProvider(Annotation
annotation);
Such methods would allow the ginjector to instantiate the Payment
object bound with the specified annotation. It could be used within
generators to instantiate a given object without having to add a
specific method to the ginjector. Moreover, only the implementations
of Payment bound with an annotation would be compiled-in. Other
classes and non-bound implementations of Payment would be left out.
That means having:
Object getObject(Annotation annotation);
would not force-compile the entire world, just classes bound with an
annotation. If we make the reasonable assumption that such classes are
desired (not an unreasonable assumption I believe) then it is not over-
compiling anything.
I'm currently working on an implementation of this feature outside of
GIN, wrapping the Ginjector within my new GinjectorWithAnnotations.
However, I would be happy to add this directly on the Ginjector class
if you thought you would be interested in adding such a feature to
GIN's trunk. Just let me know.
Cheers,
Philippe
[1] For more info on this, see: http://code.google.com/p/gwt-platform/issues/detail?id=74#c10
[2] http://code.google.com/p/google-gin/issues/detail?id=89
Thomas Broyer
views can be in "edit mode" or "details mode" depending on the object
being edited/viewed (let's say, to make things simple, that it has a
isReadOnly() method) *and* that state can change at runtime (it's a
pessimist-lock mechanism: the user clicks a button to "lock" the
object so it can edit it –a working copy actually–, and it then
"unlocks" it and commit his changes and the object turns back to being
immutable).
To make things simple for us, we develop 2 views: an "edit view" and a
"details view". Now, to make things even easier to work with, we
thought about having a "switchable view" so that the presenter only
knows about a single view and a way to turn it from/to "edit" to/from
"details" mode (the switchable view being a proxy to either of the
concrete views depending on the edit/details mode). That means: both
concrete views implement the same given interface, and the "switchable
view" implements both that interface and a SwitchableView which adds a
method to switch between modes.
Let's see some (very classic) code:
interface MyView {
interface Delegate { ... }
void setDelegate(Delegate d);
}
class MyEditView implements MyView { ... }
class MyDetailsView implements MyView { ... }
class MyPresenter implements MyView.Delegate {
interface SwitchableMyView extends SwitchableView, MyView {
}
@Inject SwitchableMyView view;
...
view.setDelegate(this);
}
To make it work *today* I have to implement SwitchableMyView so GIN
can inject the concrete views (this is sample code, not the real
implementation):
class SwitchableMyViewImpl implements SwitchableView, MyView {
@Inject @Details Provider<MyView> details;
@Inject @Edit Provider<MyView> edit;
MyView currentView;
public void setEditMode(boolean editMode) {
currentView = editMode ? edit.get() : details.get();
}
public void setDelegate(Delegate d) {
currentView.setDelegate(d);
}
}
Given that creating such implementations is a very "mechanical" task,
it could (and thus should, computers are made for that) be automated.
Our only option today is to generate the code through an external tool
so it can be seen by GIN/Guice and the GWT Compiler.
Wouldn't it be easier though if I could use a GWT generator?
Now, as for the implementation of the generator, let's see an
alternative to what you're proposing (as I understood it): instead of
a "normal GWT generator" that would use a "global injector" and its
(in my case) getMyView(Annotation) method that I'd still have to
define by hand; how about a "GIN-aware generator"?
It would have to be in two parts: a GIN extension to process the
bindings and generate the appropriate methods in the Ginjector, and a
GWT generator (to generate the implementation of, in my case, the
interface).
The code above would look the same, the SwitchableMyViewImpl would be
generated by the GWT generator part, and the GIN extension would be
plugged-in as, e.g.
@GinExtensions(SwitchableViewExtension.class)
class SwitchableViewModule extends AbstractGinModule {
}
(the two parts are only "logical", they could very well be the same
object that both generates the "bindings" that the GIN generator will
transform into methods of the GinjectorImpl it generates, and the code
to later be compiled by GWT –class explicitly referenced from the
GinjectorImpl, so GWT will go look at it and compile it so it can
compile the GinjectorImpl itself, much like the
RequestFactoryGenerator which also creates several files)
Overall, what I'm proposing is to add extension points to GIN. The
code generator has to be "GIN-aware" anyway, so having it as a "GIN
extension" rather than a "GWT generator that would make use of a
special Ginjector feature" doesn't sound silly. Maybe (probably) the
AssistedInject support and AsyncProvider could have even been made as
an extension using this API/SPI.
Philippe Beaudoin
I agree that the need for instantiating injected classes in generators
comes up all the time. I ran into it twice already, your use case is
another example, and you can also look at the code of GUIT who have
built their own GIN extension system:
http://code.google.com/p/guit/source/browse/trunk/Guit/src/com/guit/rebind/gin/GinInjectorGenerator.java
[Incidentally, you may want to look at this for a nice alternative to
the external tool generator you're currently using.]
I think your proposal is a good idea (although I'm not sure I entirely
understand it 100%, sample code for SwitchableViewExtension would
help). I think something like that would lead to an even cleaner
mechanism for injecting generated classes. However, I think it is more
involved and will probably require more convincing to get into GIN
proper. ;)
For this reason I suggest we take your proposal over to another thread
and keep this one focused on my original idea of allowing for an
annotation-parameterized get() in the ginjector. I think my proposal
goes further than allowing injected generators, as it emulates one of
the missing feature of GIN:
- Guice lets you retrieve a provider or an instance from the injector
given or a Class<?> or a Key.
- GIN lets you retrieve a provider or an instance from the injector
given a Class<?>.
What I am proposing here is a simple mechanism to extend GIN's
functionality to match that of Guice while keeping GIN-specific design
constraints in mind. Use cases for this feature go beyond simplifying
injected generators and include any situation in which you would use
Guice's injector.getInstance(Key) or injector.getProvider(Key).
Cheers,
Philippe
> --
> You received this message because you are subscribed to the Google Groups "google-gin" group.
> To post to this group, send email to googl...@googlegroups.com.
> To unsubscribe from this group, send email to google-gin+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-gin?hl=en.
>
>
Thomas Broyer
On 17 nov, 18:37, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:
>
> I agree that the need for instantiating injected classes in generators
> comes up all the time. I ran into it twice already, your use case is
> another example, and you can also look at the code of GUIT who have
> built their own GIN extension system:
Thanks for the link! (though it's not very different from your
gin.module in GWTP, except you don't have to write the Ginjector
yourself, only GinModules; i.e. it doesn't solve the "injection within
a generated class" issue)
> [Incidentally, you may want to look at this for a nice alternative to
> the external tool generator you're currently using.]
we're instead thinking about integrating the "switch between 2 views"
within a presenter base class; we already have one which manages the
setDelegate calls, and each of our presenter access its view through a
getView method, so the plan is to move setEditMode to the presenter
instead of a SwitchableView and have our getView return the current
view; but maybe we'll rather copy GUIT's GinInjectorGenerator instead)
> I think your proposal is a good idea (although I'm not sure I entirely
> understand it 100%, sample code for SwitchableViewExtension would
> help).
example. For instance, I briefly looked at the code for the Guice
AssistedInject extension and it seems to create Binding instances and
"contribute" to the module it's installed in; the GIN Extension SPI
would allow extensions to do the same, using GIN bindings instead of
Guice ones, with the ability to reference classes by name (for
generated ones, each extension would receive a GeneratorContext so it
can create resources) rather than by Class<?>.
Just an idea!
> I think something like that would lead to an even cleaner
> mechanism for injecting generated classes. However, I think it is more
> involved and will probably require more convincing to get into GIN
> proper. ;)
integrated unless I start contributing a patch ;-) )
> For this reason I suggest we take your proposal over to another thread
> and keep this one focused on my original idea of allowing for an
> annotation-parameterized get() in the ginjector.
and my proposal sure requires a lot more work (and upfront API design)
than yours!
(just that, maybe we could work together on my proposal instead ;-) )
Philippe Beaudoin
"injection within a generator" problem is to gain access to the
ginjector instance within the generator. For example, one way is to
add a "GWT.create(MyGinjector.class);" in the generated code. This
means you have to identify MyGinjector in the generator -- which you
can do by reflection or using a GWT configuration property.
Once you have an instance of the ginjector you can use reflection to
find the correct method to call within it to instantiate any of your
dependencies. The problem, now, is that the ginjector needs to contain
a method returning your desired type. GUIT (again, IIUC) solves this
by defining their own custom Ginjector, wrapping the standard
Ginjector and automatically adding methods to it.
This strikes me as a sound idea to tackle your problem, but to be
really useful it would need to be done in a more generic way. One idea
-- and maybe that's what you were proposing -- might be for the
generator to somehow publish all the dependencies it needs. GIN could
then collect all these extra dependencies, add methods to the
ginjector somehow, and report back the name of these methods to the
generator so it can use them in the generated code. I think all of
this can be done entirely outside of GIN -- although it would probably
easier to do wighin GIN. I would love to work with you on this. [*]
An alternative (and that's what I'm aiming at with my proposal) would
be to have the ginjector support some kind of parameterized method.
There you go, my original proposal has completely derailed... :) I
still want to do it, however,as I'm already working on it, although
outside of GIN.
Cheers,
Philippe
[*] Even better than this would be for the generator to not care about
publishing its dependencies and to simply generate code containing
@Inject wherever needed. This looks very hard to do, however, as it
would require us to first generate the code, then load the class
(using some custom class loader?) to parse the AST and find the
dependencies, then bind the generated class in GIN... Anyway,
half-baked thought but looks hard.
Philippe Beaudoin
1) Would you be interested in the ginjector supporting key-like
getters, or the form Payment get(Annotation)
2) Would you be interested in adding an extension system to facilitate
creating things like injected generators?
Thomas Broyer
On 17 nov, 23:39, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:
> "injection within a generator" problem is to gain access to the
> ginjector instance within the generator. For example, one way is to
> add a "GWT.create(MyGinjector.class);" in the generated code. This
> means you have to identify MyGinjector in the generator -- which you
> can do by reflection or using a GWT configuration property.
>
> Once you have an instance of the ginjector you can use reflection to
> find the correct method to call within it to instantiate any of your
> dependencies. The problem, now, is that the ginjector needs to contain
> a method returning your desired type. GUIT (again, IIUC) solves this
> by defining their own custom Ginjector, wrapping the standard
> Ginjector and automatically adding methods to it.
>
> This strikes me as a sound idea to tackle your problem, but to be
> really useful it would need to be done in a more generic way. One idea
> -- and maybe that's what you were proposing -- might be for the
> generator to somehow publish all the dependencies it needs.
(note the generator would *not* be a GWT generator called by a
<generate-with> rule, but a GIN extension referenced from an
annotation on the Ginjector or the GinModule)
> GIN could
> then collect all these extra dependencies, add methods to the
> ginjector somehow, and report back the name of these methods to the
> generator so it can use them in the generated code.
instantiated by GIN (and because Guice/GIN cannot analyze the
generated class for dependencies, the generator gives them to GIN, as
bindings to, say, "inject class X annotated with Y as first
constructor argument") so the injection of the dependencies is done by
GIN as with any other class, not need to communicate anything back to
the generator (unless I'm missing something).
> I think all of
> this can be done entirely outside of GIN -- although it would probably
> easier to do wighin GIN. I would love to work with you on this. [*]
> publishing its dependencies and to simply generate code containing
> @Inject wherever needed. This looks very hard to do, however, as it
> would require us to first generate the code, then load the class
> (using some custom class loader?) to parse the AST and find the
> dependencies, then bind the generated class in GIN... Anyway,
> half-baked thought but looks hard.
If Guice used some abstraction instead of direct java.reflect.* class,
it would be possible to plug the com.google.gwt.core.ext.typeinfo.* as
the source, but it doesn't AFAICT and I don't see any reason it would
change.
Using a custom ClassLoader could be an option too, and reconstructing
a Class from a JClassType maybe isn't that hard (using something like
Javassist for instance); I'll have to investigate...
Note the generator would still have to generate a binding from the
interface/class to the generated implementation, then I suppose Guice
would get it from the ClassLoader and find the dependencies itself (no
need to "parse the AST and find the dependencies, then bind the
generated class in GIN").
If possible (and there's no reason it could given what DevMode is
capable), could be both easier for the "GIN extension" writer *and*
even to implement the extension mechanism in GIN itself!
Peter Schmitt
Yes!
If Guice used some abstraction instead of direct java.reflect.* class,
it would be possible to plug the com.google.gwt.core.ext.typeinfo.* as
the source, but it doesn't AFAICT and I don't see any reason it would
change.
Using a custom ClassLoader could be an option too, and reconstructing
a Class from a JClassType maybe isn't that hard (using something like
Javassist for instance); I'll have to investigate...
Note the generator would still have to generate a binding from the
interface/class to the generated implementation, then I suppose Guice
would get it from the ClassLoader and find the dependencies itself (no
need to "parse the AST and find the dependencies, then bind the
generated class in GIN").
If possible (and there's no reason it could given what DevMode is
capable), could be both easier for the "GIN extension" writer *and*
even to implement the extension mechanism in GIN itself!
- Expand the GWT generator framework to allow me to call GWT.create programatically and inspect the results (i.e. load them into the AST).
- Expose the freshly generated/loaded classes through a custom class loader (here we should be able to leverage the dev mode infrastructure which does something similar).
- Us the above custom classloader for Guice (presumably iteratively since some of the targets are only identified and generated during the binding process) and inspect the resulting bindings that way.
- If we can call GWT.create programatically, for the first time we can actually test generators properly!
- No more "Deferred binding result type 'A' should not be abstract" errors - we can actually check if GWT.create bindings work during GIN compilation.
- No more requirements that the java sources need to be compiled before the GWT compiler runs (we can just always use the custom class loader).
Peter
Philippe Beaudoin
>
> On 17 nov, 23:39, Philippe Beaudoin <philippe.beaud...@gmail.com>
>
>> really useful it would need to be done in a more generic way. One idea
>> -- and maybe that's what you were proposing -- might be for the
>> generator to somehow publish all the dependencies it needs.
>
> Yes, that's what I'm proposing.
>
> (note the generator would *not* be a GWT generator called by a
> <generate-with> rule, but a GIN extension referenced from an
> annotation on the Ginjector or the GinModule)
Ok, I think I'm beginning to grasp your idea, and I like it.
Also, do we need to use annotations? Maybe we could call something like:
bind(Foo.class).toGinerator(FooGinerator.class);
in the module? Since the module is evaluated at code-generation time
anyway... This might require some more hooks into Guice as it's the
one interpreting the module, and I believe it's currently not that
easy to hijack its DSL.
[Ginerator, such a great name. ;)]
>> GIN could
>> then collect all these extra dependencies, add methods to the
>> ginjector somehow, and report back the name of these methods to the
>> generator so it can use them in the generated code.
>
> That's not necessary: the generated class is supposed to be
> instantiated by GIN (and because Guice/GIN cannot analyze the
> generated class for dependencies, the generator gives them to GIN, as
> bindings to, say, "inject class X annotated with Y as first
> constructor argument") so the injection of the dependencies is done by
> GIN as with any other class, not need to communicate anything back to
> the generator (unless I'm missing something).
Ok, let me try to rehash to see if I understand your proposal:
- Gin detects a binding from Foo to a FooGinerator in the module
- Gin calls FooGinerator.collectDependencies() which returns, say, a
dependency on Bar.
- Gin calls FooGinerator.generateClass() which generates the class and
returns "com.google.client.FooImpl".
- Gin creates the following method in the ginjector:
Provider<Foo> getFooProvider() {
return new com.google.client.FooImpl( getBarProvider().get() );
}
Something like that?
One question: how easy is it to generate a class outside the standard
GWT <generate-with> path? Do we have to worry about cascading
generation? (i.e. FooImpl calling GWT.create())
>> I think all of
>> this can be done entirely outside of GIN -- although it would probably
>> easier to do wighin GIN. I would love to work with you on this. [*]
> [...]
>> [*] Even better than this would be for the generator to not care about
>> publishing its dependencies and to simply generate code containing
>> @Inject wherever needed. This looks very hard to do, however, as it
>> would require us to first generate the code, then load the class
>> (using some custom class loader?) to parse the AST and find the
>> dependencies, then bind the generated class in GIN... Anyway,
>> half-baked thought but looks hard.
>
> Yes!
Yes to: looks hard, or to the fact that it would be great?
> If Guice used some abstraction instead of direct java.reflect.* class,
> it would be possible to plug the com.google.gwt.core.ext.typeinfo.* as
> the source, but it doesn't AFAICT and I don't see any reason it would
> change.
> Using a custom ClassLoader could be an option too, and reconstructing
> a Class from a JClassType maybe isn't that hard (using something like
> Javassist for instance); I'll have to investigate...
Not sure why you would need to recreate a JClassType from a java type
(the generator gives you back to fully qualified class name, no?), but
in case you can, Gin's KeyUtil has a bunch of methods for that:
http://code.google.com/p/google-gin/source/browse/trunk/src/com/google/gwt/inject/rebind/util/KeyUtil.java?spec=svn130&r=61#132
> Note the generator would still have to generate a binding from the
> interface/class to the generated implementation, then I suppose Guice
> would get it from the ClassLoader and find the dependencies itself (no
> need to "parse the AST and find the dependencies, then bind the
> generated class in GIN").
> If possible (and there's no reason it could given what DevMode is
> capable), could be both easier for the "GIN extension" writer *and*
> even to implement the extension mechanism in GIN itself!
The way I see it, the module provides the binding. The goal of the
class loader is simply to make the generated code accessible via
reflection to identify the dependencies and injection points
automatically.
Philippe Beaudoin
> I unfortunately haven't had the time to fully explore this and especially
> need to talk to the GWT team. But essentially your musings above are very
> similar to what I'd like to do:
>
> Expand the GWT generator framework to allow me to call GWT.create
> programatically and inspect the results (i.e. load them into the AST).
A first step would be to skip all the deferred binding performed by
GWT.create and to invoke directly a generator specified in the module.
> Expose the freshly generated/loaded classes through a custom class loader
> (here we should be able to leverage the dev mode infrastructure which does
> something similar).
Just looked quickly through GWT code and I wonder if we could use
their own class loader. Take a look there:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/dev/shell/ModuleSpace.java#646
And there:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/dev/shell/CompilingClassLoader.java
> Us the above custom classloader for Guice (presumably iteratively since some
> of the targets are only identified and generated during the binding process)
> and inspect the resulting bindings that way.
Again, assuming we do not try to mix deferred binding and gin
injection, I think we could all the classes to generate are exposed in
the module, so no need for iterative generation.
> These changes allow us to do several great things:
>
> If we can call GWT.create programatically, for the first time we can
> actually test generators properly!
> No more "Deferred binding result type 'A' should not be abstract" errors -
> we can actually check if GWT.create bindings work during GIN compilation.
> No more requirements that the java sources need to be compiled before the
> GWT compiler runs (we can just always use the custom class loader).
>
> And of course we can finally have generated code use Gin - and vice versa.
> All of this will take time though, since we probably have to make changes to
> both Guice and GWT and my bandwidth is limited. I can however provide more
> direct access to the people running those projects so that should help get
> reviews and such. :) In the meantime, maybe extensions are an interesting
> way to go (they might prove useful no matter what anyhow) and of course we
> should not forget that there are additional features that we need: enabling
> default-access injections and child-injectors/private modules are good
> examples which we should at least have an idea about so we don't build
> something that doesn't work with those things.
> What do you think? :)
I would love to bounce these ideas with people more closely involved
in GIN and GWT. I agree with you we should take things step by step.
In order of difficulty I see:
1) Emulation for get(Key) in the ginjector via Foo get(Annotation);
2) Support for extensions (Thomas proposal)
3) Reflective inspection of generated classes to identify dependencies
and injection points
What do you think?
Philippe
Thomas Broyer
On 18 nov, 03:09, Peter Schmitt <ara...@gmail.com> wrote:
>
> > If Guice used some abstraction instead of direct java.reflect.* class,
> > it would be possible to plug the com.google.gwt.core.ext.typeinfo.* as
> > the source, but it doesn't AFAICT and I don't see any reason it would
> > change.
> > Using a custom ClassLoader could be an option too, and reconstructing
> > a Class from a JClassType maybe isn't that hard (using something like
> > Javassist for instance); I'll have to investigate...
> > Note the generator would still have to generate a binding from the
> > interface/class to the generated implementation, then I suppose Guice
> > would get it from the ClassLoader and find the dependencies itself (no
> > need to "parse the AST and find the dependencies, then bind the
> > generated class in GIN").
> > If possible (and there's no reason it could given what DevMode is
> > capable), could be both easier for the "GIN extension" writer *and*
> > even to implement the extension mechanism in GIN itself!
>
> I unfortunately haven't had the time to fully explore this and especially
> need to talk to the GWT team. But essentially your musings above are very
> similar to what I'd like to do:
>
> does something similar).
> process) and inspect the resulting bindings that way.
>
> These changes allow us to do several great things:
>
> actually test generators properly!
> - No more "Deferred binding result type 'A' should not be abstract"
> compilation.
>
> And of course we can finally have generated code use Gin - and vice versa.
If a generator generates GIN-aware code, there's no reasonit couldn't
integrate into GIN's own extension mechanism (if any). I'd even go
farther: if it generates code relying on GIN being used, it shouldn't
be a "standard" GWT generator, that could be used without GIN; and if
it can generate code that can use (be used by) GIN or be manually
injected (similar to how GWT-RPC generates classes that also implement
ServiceDefTarget so you can inject an RpcRequestBuilder and/or service
entry point), there's no reason it couldn't be a "hybrid generator".
> All of this will take time though, since we probably have to make changes to
> both Guice and GWT and my bandwidth is limited. I can however provide more
> direct access to the people running those projects so that should help get
> reviews and such. :) In the meantime, maybe extensions are an interesting
> way to go (they might prove useful no matter what anyhow) and of course we
> should not forget that there are additional features that we need: enabling
> default-access injections and child-injectors/private modules are good
> examples which we should at least have an idea about so we don't build
> something that doesn't work with those things.
>
> What do you think? :)
GWT or Guice, but it could ask a little more work to "GIN extension"
developers (or not, depending what we're capable of doing; and it
would still be simpler overall than Guice extensions ;-) ).
The idea would basically be the same as you describe minus the
programmatic call to GWT.create; with generators being "GIN
extensions" rather than "standard" GWT generators.
(BTW, using a custom ClassLoader shouldn't be an issue with Guice,
given that it already works in OSGi or similar environments which
already do so)
Thomas Broyer
On 18 nov, 07:45, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:
>
> > On 17 nov, 23:39, Philippe Beaudoin <philippe.beaud...@gmail.com>
>
> >> This strikes me as a sound idea to tackle your problem, but to be
> >> really useful it would need to be done in a more generic way. One idea
> >> -- and maybe that's what you were proposing -- might be for the
> >> generator to somehow publish all the dependencies it needs.
>
> > Yes, that's what I'm proposing.
>
> > (note the generator would *not* be a GWT generator called by a
> > <generate-with> rule, but a GIN extension referenced from an
> > annotation on the Ginjector or the GinModule)
>
> Ok, I think I'm beginning to grasp your idea, and I like it.
> Also, do we need to use annotations? Maybe we could call something like:
> bind(Foo.class).toGinerator(FooGinerator.class);
> in the module? Since the module is evaluated at code-generation time
> anyway...
and Provider<?> inner classes, so it has to be "client code" (IIUC how
GIN works).
> This might require some more hooks into Guice as it's the
> one interpreting the module, and I believe it's currently not that
> easy to hijack its DSL.
"adapted", and its Binder is also a GinBinder and not a Guice Binder,
so it's adapted too. Which means that adding DSL to the GinBinder
doesn not imply "hijacking" the DLS of Guice.
> Ok, let me try to rehash to see if I understand your proposal:
> - Gin detects a binding from Foo to a FooGinerator in the module
module so it injects bindings at the Guice level to a special Provider
(similar to how GIN already uses a special GwtDotCreateProvider as a
"marker"); that provider would probably be a ProviderWithDependencies.
> - Gin calls FooGinerator.collectDependencies() which returns, say, a
> dependency on Bar.
ProviderWithDependencies#getDependencies which would route it to the
extension's getDependencies.
> - Gin calls FooGinerator.generateClass() which generates the class and
> returns "com.google.client.FooImpl".
> - Gin creates the following method in the ginjector:
> Provider<Foo> getFooProvider() {
> return new com.google.client.FooImpl( getBarProvider().get() );
>
> }
>
> Something like that?
> One question: how easy is it to generate a class outside the standard
> GWT <generate-with> path?
Ginjector.
And as soon as you have a GeneratorContext, you call tryCreate on it
and it creates a resource. If the class is used from the one that's
being generated (the GinjectorImpl), then GWT will compile it (because
it needs it to compile the GinjectorImpl).
For comparison, when you create GWT.create on a UiBinder, it creates
the UiBinder_Impl and the implicit ClientBundle and Messages for the
template. Similarly, when you GWT.create a RequestFactory, the
generator creates a RequestFactoryImpl, and "impl" classes for each
returned RequestContext and each referenced EntityProxy.
> Do we have to worry about cascading
> generation? (i.e. FooImpl calling GWT.create())
> > If Guice used some abstraction instead of direct java.reflect.* class,
> > it would be possible to plug the com.google.gwt.core.ext.typeinfo.* as
> > the source, but it doesn't AFAICT and I don't see any reason it would
> > change.
> > Using a custom ClassLoader could be an option too, and reconstructing
> > a Class from a JClassType maybe isn't that hard (using something like
> > Javassist for instance); I'll have to investigate...
>
> Not sure why you would need to recreate a JClassType from a java type
> (the generator gives you back to fully qualified class name, no?),
just-generated class, but you don't have it actually, so yes the fully
qualified class name is enough (using a "CompilingClassLoader" as the
DevMode does, to compile the class on-the-fly).
> but
> in case you can, Gin's KeyUtil has a bunch of methods for that:http://code.google.com/p/google-gin/source/browse/trunk/src/com/googl...
> > Note the generator would still have to generate a binding from the
> > interface/class to the generated implementation, then I suppose Guice
> > would get it from the ClassLoader and find the dependencies itself (no
> > need to "parse the AST and find the dependencies, then bind the
> > generated class in GIN").
> > If possible (and there's no reason it could given what DevMode is
> > capable), could be both easier for the "GIN extension" writer *and*
> > even to implement the extension mechanism in GIN itself!
>
> The way I see it, the module provides the binding. The goal of the
> class loader is simply to make the generated code accessible via
> reflection to identify the dependencies and injection points
> automatically.
used as your proposed FooGinerator above, so it first has to add
special bindings (from any AsyncProvider to the async extension, from
any special-provider installed by a GinFactoryProviderBuilder to the
assistedinject extension, from any SwitchableView to the
SwitchableView extension, etc.).
Philippe Beaudoin
I really like your idea and I think I understand it enough to start
working on it. Now a couple of things I'm not 100% clear on:
1) I'm still not sure I see why we could not do:
bind(Foo.class).to(MyGinGenerator.class)
This, to me, looks much nicer than say:
@GinExtensions(MyGinExtension.class)
on the ginjector. Looking at GIN's code, both lines would be analyzed
at rebind time so I don't see what you could do in one that you
couldn't do in the other.
2) Should we first go with a GinGenerator.getDependencies() method
(and some setDependencies() on the code generated by the
GinGenerator?) or do we only expect a GWT Generator and analyse the
generated code for @Inject dependencies and injection points?
Looking forward to working on this with you!
Cheers,
Philippe
Thomas Broyer
> Thomas,
>
> I really like your idea and I think I understand it enough to start
> working on it. Now a couple of things I'm not 100% clear on:
>
> 1) I'm still not sure I see why we could not do:
> bind(Foo.class).to(MyGinGenerator.class)
> This, to me, looks much nicer than say:
> @GinExtensions(MyGinExtension.class)
> on the ginjector. Looking at GIN's code, both lines would be analyzed
> at rebind time so I don't see what you could do in one that you
> couldn't do in the other.
The thing is that the GinModule is client-code (both used in Java at
compile-time and translated to JavaScript for the @Provides methods
and inner classes, providers for instance; the configure() method
won't be called in the generated code, so it'll be pruned by the
compiler, but it still has to be "translatable"), this means the
MyGinExtension has to be translatable too. You don't have that issue
with classes referenced from annotations (see @Service and @ProxyFor
in RequestFactory for instance).
I'm not sure what it'd buy you really (see below) but it could only be
possible if each and every extension provides a <super-source> no-op
implementation; easy but still cumbersome. Now let's see the
differences with my annotation-based approach: if your module
referenced in @GinExtensions can tell the GinGenerator that it handles
bindings to specific types (i.e. whichever their parameter types, for
generic types, or maybe even their specific type, if reacting on
annotations) I think there's no need for a bind().toExtension(). The
benefit of your proposal is that no 2 extensions can conflict because
every binding has to be explicit; the drawback is that... every
binding has to be explicit!
Imagine 30 screens where I would need a SwitchableView (I haven't
checked but I suspect it'll be in this order of magnitude, probably
even more), it means 30 bind().toExtension() in my GinModule! On the
other hand, I'm proposing only adding a
@GinExtensions(SwitchableViewExtension.class) on the GinModule to
handle all subclasses of SwichableView; and that could be used to
refactor into extensions the AssistedInject, AsyncProvider and
RemoteService special-casings in GIN.
> 2) Should we first go with a GinGenerator.getDependencies() method
> (and some setDependencies() on the code generated by the
> GinGenerator?) or do we only expect a GWT Generator and analyse the
> generated code for @Inject dependencies and injection points?
Well, GIN's com.google.gwt.inject.rebind.binding.Binding has
getRequiredKeys and writeCreatorMethod, and all existing "extensions"
have specific bindings (AsyncProviderBinding, FactoryBinding and
RemoteServiceProxyBinding), so maybe it's the way to go; enhancing the
API with a way to create any file you want (so you can reference the
generated class from the writeCreatorMethod). I think a
CompilingClassLoader could later be plugged behind that API (Guice's
com.google.inject.spi.InjectionPoint makes it easy to analyze a class
and grab its dependencies, which makes it "easy" to build the
RequiredKeys and generate the injection code for writeCreatorMethod).
> Looking forward to working on this with you!
What do you think would be the best way to collaborate? Fork on
github? (I'm not used to DVCS but it could be the perfect excuse to
start using it) Exchange patches on codereview.appspot.com? (so each
one is free to work with its SVN working copy and/or local branches in
Git (or Mercurial)) Or maybe "collaboratively" spec it all in Wave or
Docs before coding it?
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
Philippe Beaudoin
> On Sat, Nov 20, 2010 at 7:41 PM, Philippe Beaudoin wrote:
>> Thomas,
>>
>> I really like your idea and I think I understand it enough to start
>> working on it. Now a couple of things I'm not 100% clear on:
>>
>> 1) I'm still not sure I see why we could not do:
>> bind(Foo.class).to(MyGinGenerator.class)
>> This, to me, looks much nicer than say:
>> @GinExtensions(MyGinExtension.class)
>> on the ginjector. Looking at GIN's code, both lines would be analyzed
>> at rebind time so I don't see what you could do in one that you
>> couldn't do in the other.
>
> The thing is that the GinModule is client-code (both used in Java at
> compile-time and translated to JavaScript for the @Provides methods
> and inner classes, providers for instance; the configure() method
> won't be called in the generated code, so it'll be pruned by the
> compiler, but it still has to be "translatable"), this means the
> MyGinExtension has to be translatable too. You don't have that issue
> with classes referenced from annotations (see @Service and @ProxyFor
> in RequestFactory for instance).
Gotcha! (Finally...) I also appreciate your desire to bind a bunch of
interfaces at once to the same generator. This is specific to the fact
that we are binding to "generators" which may inspect the methods
provided in the interface to yield various implementations. To me, it
calls for a binding of this type:
bindAll(SwitchableView.class).to(GinGenerator.class); [*]
But this brings us back to the problem that GinGenerator must be
client code... So, let's go with a @GinExtension annotation.
Still, I think it's a bit weird that some of the bindings are done in
modules and some in the extensions.
However, maybe these GinExtension could be expected to have a
configure() method with bindings such as the above? And maybe to
ability to install() some GinModules? This way a single gin extension
could configure all the bindings it needs, including bindings to
GinGenerators, but it wouldn't be expected to run as client code? In
other words, GinExtensions would just be GinModules with slightly less
privileges.
>> 2) Should we first go with a GinGenerator.getDependencies() method
>> (and some setDependencies() on the code generated by the
>> GinGenerator?) or do we only expect a GWT Generator and analyse the
>> generated code for @Inject dependencies and injection points?
>
> Well, GIN's com.google.gwt.inject.rebind.binding.Binding has
> getRequiredKeys and writeCreatorMethod, and all existing "extensions"
> have specific bindings (AsyncProviderBinding, FactoryBinding and
> RemoteServiceProxyBinding), so maybe it's the way to go; enhancing the
> API with a way to create any file you want (so you can reference the
> generated class from the writeCreatorMethod). I think a
> CompilingClassLoader could later be plugged behind that API (Guice's
> com.google.inject.spi.InjectionPoint makes it easy to analyze a class
> and grab its dependencies, which makes it "easy" to build the
> RequiredKeys and generate the injection code for writeCreatorMethod).
>
>> Looking forward to working on this with you!
>
> What do you think would be the best way to collaborate? Fork on
> github? (I'm not used to DVCS but it could be the perfect excuse to
> start using it) Exchange patches on codereview.appspot.com? (so each
> one is free to work with its SVN working copy and/or local branches in
> Git (or Mercurial)) Or maybe "collaboratively" spec it all in Wave or
> Docs before coding it?
I propose a Wave doc for the design and a mercurial repo on Google
Code for the dev. (Or GitHub, but I'm more fluent in mercurial.) Code
reviews on Rietveld. DVCS are really easy and fun to use, you have to
pick them up. ;)
Cheers,
Philippe
[*] In fact, a bindAll() method would be useful in Guice in some
situations. I have created something like that in Jukito where
forceMock(Foo.class) binds all classes assignable to Foo to a
MockProvider<>.
Thomas Broyer
>
> Still, I think it's a bit weird that some of the bindings are done in
> modules and some in the extensions.
It's not really different to GWT generators, and to the existing AsyncProvider.
> However, maybe these GinExtension could be expected to have a
> configure() method with bindings such as the above? And maybe to
> ability to install() some GinModules? This way a single gin extension
> could configure all the bindings it needs, including bindings to
> GinGenerators, but it wouldn't be expected to run as client code? In
> other words, GinExtensions would just be GinModules with slightly less
> privileges.
Any concrete use-case?
How about rather having to use the extension as an install(someModule)
or @GinModules(SomeModule.class), with the installed module being
annotated with @GinExtension (and/or extending a special-cased
GinModule).
Servlet integration in Guice is done that way for instance: if you
want RequestScope and SessionScope (but not the specific DSL) you just
install(new ServletModule()). Refactoring AssistedInject as a GIN
extension could work that way too: you use FactoryModuleBuilder
explicitly, so the installed module could be annotated with
@GinExtension (instead of having to use both FactoryModuleBuilder and
@GinExtension to use the AssistedInject extension).
> I propose a Wave doc for the design
I've created a world-readable, group-writeable Wave.
https://wave.google.com/wave/waveref/googlewave.com/w+BcDOfmlPA
For the moment, please do only add comments in separate blips and
leave the main document editing to Philippe, Peter and myself.
> and a mercurial repo on Google Code for the dev.
Or maybe Peter would let us use a branch on the GIN repo?
> (Or GitHub, but I'm more fluent in mercurial.)
GitHub has the advantage of "git svn", but otherwise I don't care at all.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
Philippe Beaudoin
> On Sun, Nov 21, 2010 at 12:00 AM, Philippe Beaudoin wrote:
>>
>> Still, I think it's a bit weird that some of the bindings are done in
>> modules and some in the extensions.
>
> It's not really different to GWT generators, and to the existing AsyncProvider.
>
>> However, maybe these GinExtension could be expected to have a
>> configure() method with bindings such as the above? And maybe to
>> ability to install() some GinModules? This way a single gin extension
>> could configure all the bindings it needs, including bindings to
>> GinGenerators, but it wouldn't be expected to run as client code? In
>> other words, GinExtensions would just be GinModules with slightly less
>> privileges.
>
> Any concrete use-case?
No, I think it's just a question of trying to match user's
expectancies as much as possible. Personally, if I some interface
bound to some implementation (generated or not), I expect to find a
corresponding binding in one of the modules. I could be convinced
otherwise.
I'm taking the rest of this discussion to the Wave.
Peter Schmitt
Or maybe Peter would let us use a branch on the GIN repo?
Luis Solano
I would like to know if there are any advances in this area, I'm
really interested.
Thank you!
Peter Schmitt
Philippe Beaudoin
looking pretty good and I was using it to work on some extensions of
my own. If you need, I'm happy to help porting your patch to the
recent AST/reflection changes as soon as they are in trunk.
Cheers,
Philippe
Thomas Broyer
> I want to cast my vote for fastracking this too.
+1
(having it in 1.1 would be awesome !)
Peter Schmitt
--
Thomas Broyer
Stefano Ciccarelli
Peter Schmitt
--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-gin/-/KsRUkkv5dwsJ.
Bram Wiekens
On Wednesday, January 4, 2012 7:14:26 PM UTC+1, Aragos wrote:
Hi Stefano,unfortunately this got delayed a lot and isn't ready yet since the work on private modules introduced a lot of unanticipated problems that we're still dealing with.
Peter
On Wed, Jan 4, 2012 at 15:52, Stefano Ciccarelli <--> wrote:
Hello!What about this one? Is it in the trunk now?ByeStefanoTo view this discussion on the web visit https://groups.google.com/d/msg/google-gin/-/KsRUkkv5dwsJ.--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To unsubscribe from this group, send email to google-gin+unsubscribe@googlegroups.com.
Bram Wiekens
Bram Wiekens
On Wednesday, November 17, 2010 7:55:16 AM UTC+1, Philippe Beaudoin wrote:
Hello all!
I regularly need to instantiate injected classes from my code produced
via GWT generators. For example, my recent patch to support gin-
injected widgets in UiBinder code requires this. [1]
For the moment, the only option I have found is for the generated
class to grab the global ginjector and use it to instantiate the
class. This, however, requires the user to add a method in the
ginjector returning the desired type. This extra burden of adding a
method there is very tedious and does not keep change local.
Now, this would be solved if GIN supported Guice-like accessors in the
ginjector, as proposed in issue 89 [2]. However, as discussed by
aragos in this issue, it is not desirable in GIN because it would
force-compile a lot of classes that might not be needed. (All classes
if you take into account JIT binding and GWT.create instantiations.)
I have come up with a different proposal that would allow me to
elegantly solve the problem of instantiating injected classes in
generators without polluting the compiled code. What I propose is to
allow the ginjector to contain methods taking a single Annotation
parameter. For example:
Payment getPayment(Annotation annotation);
AsyncProvider<Payment> getPaymentAsyncProvider(Annotation
annotation);
Such methods would allow the ginjector to instantiate the Payment
object bound with the specified annotation. It could be used within
generators to instantiate a given object without having to add a
specific method to the ginjector. Moreover, only the implementations
of Payment bound with an annotation would be compiled-in. Other
classes and non-bound implementations of Payment would be left out.
That means having:
Object getObject(Annotation annotation);
would not force-compile the entire world, just classes bound with an
annotation. If we make the reasonable assumption that such classes are
desired (not an unreasonable assumption I believe) then it is not over-
compiling anything.
I'm currently working on an implementation of this feature outside of
GIN, wrapping the Ginjector within my new GinjectorWithAnnotations.
However, I would be happy to add this directly on the Ginjector class
if you thought you would be interested in adding such a feature to
GIN's trunk. Just let me know.
Cheers,
Philippe
[1] For more info on this, see: http://code.google.com/p/gwt-platform/issues/detail?id=74#c10
[2] http://code.google.com/p/google-gin/issues/detail?id=89
Brandon Donnelson
Peter Schmitt
--
You received this message because you are subscribed to the Google Groups "google-gin" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-gin/-/leQzzSbN5CIJ.
To unsubscribe from this group, send email to google-gin+...@googlegroups.com.
