Declaring gin modules in as configuration properties in the GWT module

[GoogleCodeExporter]

It looks like the only way to specify a gin module is to modify the
content of the @GinModule annotation on the ginjector. In our case,
this forces us to swap .java files based on the configuration we're
building. We would much rather just swap out a .gwt.xml file instead.

This could be done if GIN used a configuration property, in addition
to the @GinModule annotation, to list the required modules. Something
similar has been done in the GUIT project as you can see there:
http://code.google.com/p/guit/source/browse/trunk/Guit/src/com/guit/rebind/gin/G
inInjectorGenerator.java#80

This is discussed in this forum thread:
http://groups.google.com/group/google-gin/browse_thread/thread/b42a4464c7f54f66?
hl=en

Original issue reported on code.google.com by philippe.beaudoin on 23 Nov 2010 at 7:02

[GoogleCodeExporter]

Original comment by aragos on 27 Nov 2010 at 7:37

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

It would be great to add support not only for listing modules in configuration 
property, but also in deferred binding properties.

Original comment by krot.vya...@gmail.com on 7 Dec 2010 at 7:28

[GoogleCodeExporter]

Do you mean install()-ing a module based on a configuration property? Or 
switching between bindings based on that? 

If so, I've been thinking about it and there are quite a few problems with 
that. For now, I have been able to get around that problem using the fact that 
Gin relies on GWT.create() for unbound interfaces, combined with a 
<replace-with> in the GWT module.

Original comment by philippe.beaudoin on 7 Dec 2010 at 7:52

[GoogleCodeExporter]

I mean installing module based on configuration property in addition to those, 
which are already declared via @GinModules annotation. I bind most of stuff in 
module set via annotation and all specific configuration goes in modules which 
I choose based on properties.
I am not very familiar with gin source code, but I managed to do it with just a 
few lines of code in BindingsProcessor.populateModulesFromInjectorInterface 
method. It works for me, but I didn't test it well, so problems may appear 
later.

Original comment by krot.vya...@gmail.com on 9 Dec 2010 at 9:21

[GoogleCodeExporter]

First version of a patch attached. Includes a new series of client tests for 
this feature.

Please review at:
http://codereview.appspot.com/3732045/

Original comment by philippe.beaudoin on 19 Dec 2010 at 8:47

Attachments:

• issue129.patch

[GoogleCodeExporter]

Original comment by aragos on 21 Jan 2011 at 9:22

• Changed state: Review

[GoogleCodeExporter]

Submitted in r167.

Original comment by aragos on 7 Feb 2011 at 5:42

• Changed state: Fixed

[GoogleCodeExporter]

One thought about this that I had recently: The modules will be applied to any 
ginjector in an application containing this property - is there any way to 
restrict the ginjector(s) it gets applied to?

Original comment by aragos on 22 Feb 2011 at 4:53

[GoogleCodeExporter]

Ah! I did not think of this as I've never used more than one ginjector. Maybe 
this would justify an annotation-based mechanism like the one you proposed on 
the forum, quoting you:
  @GinModules optionally take the string for the property name to be read
What I like about this is that we could allow for both configuration properties 
(multi-valued or not) and regular deferred binding properties. As discussed in 
the code review, regular deferred binding properties are more flexible since 
GWT allows to define them conditionally in the XML -- based, say, on the 
browser type.

A simpler -- albeit less flexible -- solution would be to use the name of the 
ginjector class to generate the name of the multi-valued configuration 
property. (Instead of defining a single global one in Inject.gwt.xml)

I suggest we open a new issue for this and would be more than happy to work on 
it.

Original comment by philippe.beaudoin on 22 Feb 2011 at 6:05

[GoogleCodeExporter]

nice feature! thanks

Original comment by gal.dol...@gmail.com on 22 Feb 2011 at 6:11