Description Michael Golubev 2011-10-25 12:28:59 EDT

Actually the execution of the gmfgraph templates is done at the bridge stage -- figure code is being generated as part of the GmfGen model creation and is being stored as text in the InnerClassViewmap. 

Also, the InnerClassViewmap has no references back to original gmfgraph model, which leads to passing some parts of that input (say fixed color or font) as viewmap Attributes. 

Finally, the actual state does not suit any cases when the presence of the custom figure requires the code being generated not only for XXXEditPart#getFigure() method but also for other places in the surrounding code (which is the case, e.g, for Button's or for dynamic changing of the figure properties based on semantic state). 

To solve this problem the concept of gmfgen::ModeledViewmap had been introduced in 2.3 that is effectively just a reference back to the GMFGraph instance (in most cases it is some Figure Descriptor). 
In this scheme the bridge 
- does not involve ANY code-generation and all the code which is actually executed at the codegeneration phase. 
- ModeledViewmap has a direct reference back to gmfrpah model, and eliminates the encode some details of that into the weird attribute's of gmfgen model
- this reference allows extender to create AROUNDs that takes the custom figure into account and allows to generate surrounding code. 

=> 

We need to 
- actually factor the invocation of gmfgraph templates (possibly Around'ed) at the codegeneration phase, and 
- allow to optionally disable the old-way generation at the bridge from UI