Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 361958

Summary:

Support figure code generation based on the ModeledViewmap's

Product:

[Modeling] GMF-Tooling

Reporter:

Michael Golubev <borlander>

Component:

Generation / Templates

Assignee:

Michael Golubev <borlander>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

borlander

Version:

3.0

Flags:

borlander: juno+

Target Milestone:

3.0M6

Hardware:

OS:

Windows XP

Whiteboard:

Extensibility

Attachments:

Description	Flags
Mindmap GMF GenModel that uses ModeledViewmap insted of InnerClassViewmap	none

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

Comment 1 Guillaume Hillairet

2011-10-25 12:39:22 EDT

Created attachment 205934 [details]
Mindmap GMF GenModel that uses ModeledViewmap insted of InnerClassViewmap

Model generated from bridge transformation that enable decoupling of code generation. InnerClassViewmap are replaced by ModeledViewmap that will allow execution of code generation after gmfgen generation.

Comment 2 Michael Golubev

2012-01-13 10:00:02 EST

The code is committed to 361958-Modeled-Viewmaps-ALL branch in git. 
It includes: 
- UI option for "create generator model" wizard to enable switching to use ModeledViewmap's for all of the GenCommonBase's
- templates that handles the generation based on the ModeledViewmap's and producing code which is identical to the one generated by default
- Taipan and Taipan Port - gmfgen models created with ModeledViewmaps
- Taipan and Taipan Port sample diagrams regenerated with the changed templates

Comment 3 Michael Golubev

2012-05-30 00:26:13 EDT

Verified in RC2, see 380320