Bugzilla – Full Text Bug Listing
| Summary: | [Element Edit Service] Generation of ElementType(s) for a domain | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Patrick Tessier <Patrick.Tessier> | ||||
| Component: | Core | Assignee: | Project Inbox <mdt-papyrus-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cletavernier, yann.tanguy | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 324966 | ||||||
| Attachments: |
|
||||||
|
Description
Patrick Tessier
Created attachment 177926 [details]
mylyn/context/zip
impacted plugins
the framework generate all element types for UML. I have commited a first proposal that can only generated UML element. The service creation of UML contains a model that could be used to generated it. The generative tool related to this task consist in a specific metamodel and acceleo based code generation templates. Its goal is to improve, by modeling and generating, the declaration of a set of IElementTypes and their creation commands. The metamodel provides an abstraction of these element used in the generation process. Declaring IElementType for meta classes of a domain model gives the possibility to use the GMF Runtime Extensible Type framework to retrieve edit command for element of the domain model. In case the domain model contains a lot of IElementType to declare this task becomes very tedious. The "DomainContextDodegen" metamodel tries to alleviate the process by automatically creating a declaration node for any metaclass of the domain model (each of these nodes can be manually customized then) and then generating all required Java classes and xml (for plugin.xml file) declarations needed for these element types and related creation commands. Papyrus requires these element types as its centralized element edit service is currently fully based on the Extensible Type framework offered by GMF (with slight adaptation to ensure it does not interfere with possible use of this framework in diagram code generated by the GMF Tooling. Changes in r2668 : - "_" added in generated IElementTypes constants, name and hints (e.g. ACCEPT_CALL_ACTION) - Some useless (or manually defined part) were removed from the code generation process (e.g. Context binding...) - Handler and ElementType can be generated in different project (and separately) - The target source folder can be specified - Handler generated code was changed (possibility to specify a common super class in the model) - Generated comment were added in xml generation. In r3520: - Various changes in order to use the same model and generator for SysML elements I close this task |