[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-papyrus.dev] Custom code and code generation
|
Hi Gerard,
I agree that improving our communication would really increase our efficency. No doubt ^-^.
About the second issue, I think it would be interesting to clear up what are you referring to when talking about the lack of abstract elements and inheritance in GMF. If you are talking about, for example, abstract palettes that can be reused later, we did not have that need. Thanks to the dynamic-templates all code is generated automatically accordingly to the described model.
Thanks.
Regards,
Gabriel.
P.D.: Happy new year to every one ;)
El jue, 08-01-2009 a las 09:43 +0100, GERARD Sebastien 166342 escribió:
Hi Javier,
Thanks for this very interesting information. That is the proof (if required) that we need to improve communication between each other in order to avoid to lost time...
BTW, one of the pb with using the current tools around GMF is the absence of two very important concept: abstract element and inheritance. Do you have deal with such issue in your extensions?
Thanks,
Cheers... Sébastien.
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Francisco Javier Cano
Envoyé : mercredi 7 janvier 2009 17:18
À : Papyrus Project list
Objet : RE: [mdt-papyrus.dev] Custom code and code generation
Hello Patrick,
we at MOSKitt make heavy use of dynamic templates to make MOSKitt have the required functionality.
As an example, we use dynamic templates to provide MOSKitt with this new functionality:
- multidiagram for graphical editors.
- specify which elements are viewed in each diagram.
- editing domains shared among editors that are editing the same resource.
- drag and drop in graphical editors.
- view filtering by type.
- install edit policies on created edit parts
- customization of the editor palette via extension points.
- customization of the modeler assistant via extension points.
Some of this extra functionality uses other mechanisms such as extension points and new runtime classes.
You can take a look at MOSKitt dynamic templates in this subversion repository:
http://subversion.moskitt.org/gvcase-mdt/
or, more precisely, here:
http://subversion.moskitt.org/gvcase-mdt/trunk/es.cv.gvcase.mdt.common/dynamic-templates/
You can, also, make an extension of the gmfgen model. In MOSKitt we have two extensions to the gmfgen model, one that allows the definition of several elements as canvas and another that allows the definition of appearance behavior for the node figures.
You can find the source code of the plugins with these gmfgen model extensions here:
http://subversion.moskitt.org/gvcase-mdt/trunk/es.cv.gvcase.mdt.common.gmfextension.mutating/
http://subversion.moskitt.org/gvcase-mdt/trunk/es.cv.gvcase.mdt.common.gmfextension.appearance/
The model extensions you make to gmfgen can be taken into account in your own dynamic templates. You only need to add an IMPORT statement to make your model extension visible to XPAND.
You can see an example at the start of this dynamic template:
http://subversion.moskitt.org/gvcase-mdt/trunk/es.cv.gvcase.mdt.common/dynamic-templates/codegen/aspects/xpt/diagram/editpolicies/DiagramItemSemanticEditPolicy.xpt
We have achieved a lot in MOSKitt using dynamic templates, gmfgen model extension and extension points; and it has helped us a lot in keeping our code under control.
If you have any further questions, don't hesitate to ask.
Regards,
Javi
--
----
Francisco Javier Cano Muñoz
Programador senior
Prodevelop
www.prodevelop.es
-----Original Message-----
From: mdt-papyrus.dev-bounces@xxxxxxxxxxx on behalf of TESSIER Patrick 202707
Sent: Wed 1/7/2009 12:21
To: Papyrus Project list
Subject: [mdt-papyrus.dev] Custom code and code generation
Hi,
I was continuing working on the class diagram editor but I have some
problems that needs to be solved between going further. I have more and
more customized code and the regeneration whe modifying the GMF models
becomes more and more difficult.
For some custumization I want to do, I cannot use the "not generated"
tag. For example, for modeling the template signature, there is a
particular locator and in this case I cannot use the "not generated"
tag, because in this case there are sideeffects that will impact the
possiblities to modify the compartiment of a class. In this case, I
think that the best solution is to modify the generation template
itself.
Questions:
==> Do you confirm, I am right?
==> Who has some experience in modifying the generation template? If yes
what are the modifications that you may have done for example?
An addiitonal need I will have is to work on the gmfgen model in order
to add specific behavior, e.g. on the edit parts. But I think it will
not be sufficient, I think I will have to extend the gmfgen meta model
(and also its editor) in order to add new concepts : e.g., specific
locators, very specific parsers for stereotype label, etc. My purpose
for such modifications, is to add information in the gmfgen model that
will be needed to provide a more precise/complete, and above all
efficient, code generation. In parallel, I have post this question in
gmf newsgroup, but I would like to have your opinion also and help if
possible.
Cheers... 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 <http://www.papyrusuml.org/>
---------------------------------------------------------
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
Tel 96 371 6852 - Fax 96 337 8533
|
