| [mdt-papyrus.dev] Requirements and proposition for the modification of the gmfgen |
Hi, I send you requirements for the clazz diagram editor and a proposition of extension. Requirements that can be solved by adding extensions of gmfgnen and new generation for this meta-element. Th purposes are : 1. to be able to do inheritance betwen editparts and avoid redundancy at the generation 2. to have the possibility to set Abstract editparts. 3. to be able to refresh the figure by taking in account the feature or ereference of metaclass 4. to be able to connect its own class for init name of element. 5. to be able to precise its own locator for a borderItemEdipart. You can find my proposition in the attached zip. This is UMML file done thanks to Papyrus editor 1.10. Requirements that can be solved by modify existing generation template, the purposes are : 1.to add sytematically editpolicies removeOrphanNode and links in all editpartContainers. 2.to restructure "Diagram"ContentProvider to avoid that methods are greater than 64kb. 3.to manage set, when source and target of a link reference the same feature. Source is "feature".get(0) and target is "feature".get(1) 4.to add ConstrainedItemBorderLayoutEditPolicy policy when we have a borderItemEdipart. It remains how to change editpart and figure for the same domain model. For example: I the same diagram, we would like to display a use case as an ellipse or a classifier its depends of the choice of the appearence. Patrick --------------------------------------------------------- Patrick Tessier Research Engineer DRT LIST/DTSI/SOL/LISE CEA-Saclay 91191 Gif sur Yvette Cedex Tel: 01 69 08 48 63 www.papyrusuml.org --------------------------------------------------------- -----Message d'origine----- De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Jerome BENOIS Envoyé : vendredi 9 janvier 2009 16:09 À : gmerin@xxxxxxxxxxxxx; Papyrus Project list Objet : RE: [mdt-papyrus.dev] Custom code and code generation Hi Gabriel, Please find below my response. Le vendredi 09 janvier 2009 à 14:06 +0100, Gabriel Merin Cubero a écrit : > Hi everyone, > > First of all I would like to say that the decision of changing the M2T > language cannot be taken just because the virtues of the code editor. > If we think that the Xpand2 editor has too many drawbacks maybe a > collaboration with them would be interesting. A comprehensive > comparative should be done with the advantages and disadvantages of > each language. XPand2 already solves all the generative needs, their > templates can be overridden and even the metamodels can be extended in > a non intrusive way, does MTL improve or expand the functionality > commented before? I think MTL provide similar OO features than Xpand except AOP. A little history, the C and Java code generators initially included in PapyrusUML was wrote in Acceleo. And Acceleo is very similar as MTL. Thus the question is : Who already know Acceleo or MTL ? / Who already know Xpand in Papyrus Team ? The simplicity of the tool and the power of editor is very important for me. Indeed, with a good tooling, we will be more productive to develop templates. Also, Eclipse Papyrus is focused on OMG standards (UML ans SysML), thus it's seems logical to emphasize the usage of the MOF to Text Language standard to develop Eclipse Papyrus. > > Besides, we should really take into consideration that MTL is a very > young language. In fact, it won't be "officially born" until Galileo. > Therefore, using it now would be risky. Besides, I agree MTL is a very young language and it's an incubation project. Xpand is also an incubation project and the version use by GMF.CodeGen is a fork of Xpand provided by org.eclipse.gmf.xpand* plugins. And Xpand wasn't include in Ganymede. Also MTL is mostly developped by my Obeo colleagues and i can be the bridge between Papyrus team and MTL team to insure support for any problems. > On top of all, using two languages to do the same (with all the > learning involved) doesn't make too much sense and, I think we will > all agree, it would be counterproductive to change all the GMF > templates in order to use MTL. And, therefore, if we are not planning > to alter the generative procedure of GMF it is necessary to learn > XPand2 to customize the generative procedure. So, I precise my proposal, it's just use MTL to override Xpand templates to solve quickly our generation problems and not rewrite all GMF.Codegen in MTL. Cheers, Jérôme. _______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
BEGIN:VCARD VERSION:2.1 N:TESSIER;Patrick FN:TESSIER Patrick 202707 (Patrick.TESSIER@xxxxxx) ORG:;SOL/LLSP TITLE:Ingénieur Chercheur TEL;WORK;VOICE:(01) 69 08 48 63 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;B=E2t. 451 Pce 9;CEA SACLAY=0D=0ADRT/DTSI;GIF/YVETTE CEDEX;;91191;FRANCE LABEL;WORK;ENCODING=QUOTED-PRINTABLE:B=E2t. 451 Pce 9=0D=0ACEA SACLAY=0D=0ADRT/DTSI=0D=0AGIF/YVETTE CEDEX 91191= =0D=0AFRANCE EMAIL;PREF;INTERNET:Patrick.TESSIER@xxxxxx REV:20071011T094630Z END:VCARD
Attachment:
gmfgenExtension.zip
Description: gmfgenExtension.zip