This framework has been developed to be hightly independant of Papyrus, with some execptions, like the reuse of the Papyrus Expressions framework.
This metamodel defines how to parse a model, what information to extract from it and how to include them in the final Document. This metamodel is provided by the plugin org.eclipse.papyrus.model2doc.emf.documentstructuretemplate.
This snapshot shows the basic elements of this metamodel.
On the next snapshot we show the construction of the
EReferencePartTemplate and
EClassPartTemplate. As indicated previously, this construction allows the navigation between an object and a property of this object recursively.
The editor provided to edit the DocumentStructureTemplate metamodel is not exactly the version generated by EMF. We customized it in order to use a TransactionalEditingDomain (to ease the Papyrus integration).
We can't explain all the EMF tricks employed, configuration and so on, but we will detail the most important ones.
N.B.: The UML element to implement a UML Interface in a UML model is the element InterfaceRealization . We advise against extending other elements of this metamodel.
In general, to provide a new view, we consider that such an element has no children and we use a feature to calculate the contents of the view. That's why TreeListView and EReferenceTableView implements ILeafBodyPartTemplate.
To illustrate this description, we advise you to look at the UMLDocumentStructureTemplate metamodel which extends the base DocumentStructureTemplate metamodel to provide support for UML Stereotype and Stereotype's properties. In this metamodel, StereotypePartTemplate is defined to be at the same level than EClassPartTemplate and StereotypePropertyReferencePartTemplate to be at the same level than EReferencePartTemplate. In addition, this metamodel provides the CommentAsParagraph object, considered as a view and described as a ILeafBodyPartTemplate, which is at the same level than the EReferencePartTemplate.
Once you created your new element, you need to generate it.
N.B. if you add a property to an interface and if this interface is implemented in sub-metamodel, you will need to regenerate all these sub-metamodels too!!!
Due to the root interface IBodyPartTemplate of these element, you must provide an implementation of the method buildPartTemplateTitle. There is 2 ways to do this:
You can also provide a nicer icon in the edit plugin for your created element, just replace the default icon provided by the generation.
At this step, the new element will be available in the Creation menu of the DocumentTemplate editor.
The default property view is already managed by the EMF-Framework. If you need to change the default edition of a property, you need to create an EAnnotation with a Details Entry in your UML model as child of the property for which you need to provide a custom editor.
Then, you must register a new class extending org.eclipse.emf.edit.provider.PropertyEditorFactory
to the extension point
org.eclipse.emf.edit.propertyEditorFactories in the edit plugin for your model.
This code should be done in a plugin called org.eclipse.papyrus.integration.xxx to respect the naming convention. We advise you to manage the EMF property view, before embedding it in Papyrus (because there is shared code between them).
org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties
org.eclipse.ui.views.properties.tabbed.propertySections
, you should get something like this:<extension point="org.eclipse.ui.views.properties.tabbed.propertySections"> <propertySections contributorId="TreeOutlinePage"> <propertySection class="org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.internal.DocumentStructureTemplatePropertySection" filter="org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.internal.DocumentStructureTemplatePackageSectionFilter" id="org.eclipse.papyrus.model2doc.emf.documentstructuretemplate.properties.propertySection1" tab="advanced"> <input type="java.lang.Object"> </input> </propertySection> </propertySections> </extension>
org.eclipse.papyrus.model2doc.integration.emf.documentstructuretemplate.properties.sections.AbstractEObjectAdvancedPropertySection
. This class will provide a org.eclipse.emf.edit.ui.provider.PropertySource
, this PropertySource
will provide a custom org.eclipse.ui.views.properties.IPropertyDescriptor
.
org.eclipse.jface.viewers.IFilter
You just need to manage your new feature in the method PropertySource.createPropertyDescriptor(IItemPropertyDescriptor)
of the existing PropertySource
The mappers are in charge of reading the model and the DocumentTemplate to create the DocumentStructure.
As an example, you can look the plugin org.eclipse.papyrus.model2doc.emf.template2structure
.
org.eclipse.papyrus.model2doc.emf.template2structure.mapping.AbstractTemplateToStructureMapper<INPUT>
org.eclipse.papyrus.model2doc.emf.template2structure.structuregenerator
The Papyrus-Model2Doc Developper Tools must be installed in your Eclipse.
This generator is in charge to generate the DocumentStructure from your model and a DocumentStructureTemplate.
You must create a new class implementing org.eclipse.papyrus.model2doc.emf.template2structure.generator.ITemplate2StructureGenerator
. We recommend to extend the class org.eclipse.papyrus.model2doc.emf.template2structure.generator.AbstractDocumentStructureGenerator
This class must be registered with the extension point org.eclipse.papyrus.model2doc.emf.template2structure.structuregenerator
.
The extension point allows you to declare a parent generator (field inheritsMapperFromGenerator
) to reuse mapper declared on this parent generator.
This generator is in charge to generate the final document from a DocumentStructure.
You must create a new class implementing org.eclipse.papyrus.model2doc.emf.structure2document.generator.IStructure2DocumentGenerator
.
This class must be registered with the extension point org.eclipse.papyrus.model2doc.emf.structure2document.documentgenerator
.
The org.eclipse.papyrus.model2doc.core.styles plugin provide style metamodel. It define NamedStyle for Integer, String, Boolean and Double using single or multiple references.
Name | Description | Value type | Applies to | Odt | Docx |
---|---|---|---|---|---|
mergedWithRightCell | Merge the cell with the cell located just to the right | Boolean | Cell |
![]() |
![]() |
mergedWithBottomCell | Merge the cell with the cell located just to below | Boolean | Cell |
![]() |
![]() |
All the code to support markup languages is located into the markup folder. The provided template elements and their mappers are:
The template elements are generic, so the final user can define the input format ( Markdown, html, mediawiki, textile, ...) and the output format of the file to create ( html, ...) .
Currently, we only provides mappers from Markdown and html to html. To contribute new format, you just need to create new mappers looking existing ones and to override the method doHandlesInput to filter the supported input/output format.