search

ktmprabhu / spray

Automatically exported from code.google.com/p/spray
0 stars 0 forks source link

Improve generation gap pattern to work only with one class #287

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
Currently there are a base class and class that extends this base class 
generated. The extending base class class can be moved to src, so persisted 
customization can be done. Disadvantage is that there are a lot of classes 
generated. 

To improve this we should conside to generate either inner classes or only 
generate the default classes and only when the move action to src is used the 
default class is turned into a base class and a new default class subclassing 
the base class is produced in src-gen.

Original issue reported on code.google.com by de.abg.r...@gmail.com on 19 Jul 2013 at 11:24

GoogleCodeExporter commented 8 years ago 
I think another strategy could be the usage of dependency injection. This can 
avoid the generation of many classes as well.

Therefore Spray generates just one class. A Module for the Spray Plugin will be 
generated with the GenerationGap Pattern as done now. There the classes will be 
injected (one method for every bind).

If now someone wants to override a class he could move the Module description 
and just create a new class which extends the Spray generated class he wants to 
override. Afterwards this class can be binded in the module manually. 

I think this steps could be automated as well with a few Eclipse additions on 
the context menu.

Original comment by fabio.filippelli on 20 Jul 2013 at 9:38

GoogleCodeExporter commented 8 years ago 
Good point, should the injection approach should be taken as well. This would 
introduce Google Guice dependency into the platform.

There is even an example project (https://github.com/jeeeyul/graphiti-overview) 
where the usage of dependency injection in Graphiti is demonstrated: 
https://github.com/jeeeyul/graphiti-overview/blob/master/net.jeeeyul.erd/src/net
/jeeeyul/erd/table/AddTableFeature.xtend - here even not Java but Xtend is used 
(but this would be a too hard shift for us to migrate the templates to producte 
Xtend code instead of Java code).

Original comment by de.abg.r...@gmail.com on 21 Jul 2013 at 7:13