A good description of Generator Model is given here.
Graphical, Tooling definition and Mapping model (high-level models) together with EMF meta-model description completely determine future diagram structure. These models organize a kind of specific language for diagram definition. But these high level descriptions are not well-suited for code generation tasks. A code generator needs some more generation-specific details like class/package names for some particular generated classes, and some implementation-specific parameters to allow fine-tuning of generated code, etc. Moreover, code generation templates are able to be significantly simplified by introducing a specific Generator model.
This model operates as an intermediary between code level and design level with elements like: GenPlugin (used to hold necessary parameters for generating Eclipse plug-in), GenDiagram (used to generate diagram editor), GenClass (used to generate GEF EditParts and EditPolicies), etc. The idea of this model is to reflect all of the necessary details and simplify the code generation process as much as possible by moving some parts of code generator logic to the process of transformation from high-level GMF models to the Generator model.
GMF significantly reorganizes the diagram description while creating Generator model. The transformation from high-level GMF models to Generator model is not one-to-one transformation. GMF uses an internal, transparent transformation from the map model to the gmfgen model. GMF generator has a property that allows generated code to store model elements in two ways: Either as Single file keeping diagram visual information together with model structure or Two different files - first for model contents and second for diagram-specific visual information. The structure of model file in this situation will correspond to the file structure created by standard generated EMF editor for this domain model.
Most of the diagram code can be generated without any modifications to the Generator model that is created by automatic transformation process, or with simple modifications like:
changing diagramming plug-in name, ID, package statements, etc. These changes can be done in dedicated places in the Generator model so it is not necessary to change properties of all the elements in Generator model. Corresponding changes should be preserved on the next high-level model -> Generator model transformation such that a toolsmith will be able to change the high-level models later on and regenerate diagramming code for the updated description.
For more details on gmfgen model hints and properties supported, you can refer to this Eclipse wiki page.
Graphical, Tooling definition and Mapping model (high-level models) together with EMF meta-model description completely determine future diagram structure. These models organize a kind of specific language for diagram definition. But these high level descriptions are not well-suited for code generation tasks. A code generator needs some more generation-specific details like class/package names for some particular generated classes, and some implementation-specific parameters to allow fine-tuning of generated code, etc. Moreover, code generation templates are able to be significantly simplified by introducing a specific Generator model.
This model operates as an intermediary between code level and design level with elements like: GenPlugin (used to hold necessary parameters for generating Eclipse plug-in), GenDiagram (used to generate diagram editor), GenClass (used to generate GEF EditParts and EditPolicies), etc. The idea of this model is to reflect all of the necessary details and simplify the code generation process as much as possible by moving some parts of code generator logic to the process of transformation from high-level GMF models to the Generator model.
GMF significantly reorganizes the diagram description while creating Generator model. The transformation from high-level GMF models to Generator model is not one-to-one transformation. GMF uses an internal, transparent transformation from the map model to the gmfgen model. GMF generator has a property that allows generated code to store model elements in two ways: Either as Single file keeping diagram visual information together with model structure or Two different files - first for model contents and second for diagram-specific visual information. The structure of model file in this situation will correspond to the file structure created by standard generated EMF editor for this domain model.
Most of the diagram code can be generated without any modifications to the Generator model that is created by automatic transformation process, or with simple modifications like:
changing diagramming plug-in name, ID, package statements, etc. These changes can be done in dedicated places in the Generator model so it is not necessary to change properties of all the elements in Generator model. Corresponding changes should be preserved on the next high-level model -> Generator model transformation such that a toolsmith will be able to change the high-level models later on and regenerate diagramming code for the updated description.
For more details on gmfgen model hints and properties supported, you can refer to this Eclipse wiki page.
No comments:
Post a Comment