Hi,
The problem I see with the notation file is that this file is provided by the {oe}.gmf.notation project. Personally, I would not add non-UML2 information in a .uml file. This would be the same for the notation
file, which corresponds to GMF diagrams.
Unless there is a specific element in GMF notation to handle/contain elements which are not GMF element, I do not see how/why we should have table information in this kind of file. Unfortunately, I do not know
if GMF notation is designed to handle this kind of information.
What are the impacts on adding one file to the set of files? Load/save, delete/create/rename? What else ? Is Papyrus not designed to accept files coming from different kind of editors?
Best regards,
Rémi
------------------------------------------------------------------------------------------------------------------------------------------------
Rémi SCHNEKENBURGER
+33 (0)1 69 08 48 48
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
Point Courrier n°174
91 191 Gif sur Yvette CEDEX
www.eclipse.org/papyrus
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de VELTEN Mathieu
Envoyé : mercredi 15 février 2012 14:26
À : Papyrus Project list
Objet : Re: [mdt-papyrus.dev] EMF-Facet refactoring and Papyrus Table
Hi,
I agree with Camille, no new file please J.
I also think that it should be in the notation and not the di: perhaps notation is not a good extension name because it references the gmf notation
model but we can agree that the notation file contains all the graphical descriptions (tables + diagrams), and di is used for the window description and perhaps some other transversal information.
It seems to be the more logical for me.
Regards,
Mathieu
Hello,
I’m not favorable to a new file, as most Papyrus tools expect exactly three files (x.di, x.notation and x.uml). This would involve a lot of maintenance on these tools to take a new (and probably optional) kind
of file. The notation would probably become optional as well, as we could have a model with only tables. It seems really too complicated, and the added value is not obvious.
The notation file is probably the best place for storing the table models.
Regards,
__________________________
Camille Letavernier
+33 (0)1 69 08 00 59 -
camille.letavernier@xxxxxx
CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE)
Hi all,
As you know, EMF-Facet is finishing its refactoring. They provide new metamodels for Facet, Queries, Table, Customization, …
Of course, these API are always available in Juno, but they are deprecated. Concerning the Papyrus Table, I should create a new papyrus table metamodel to use the new EMF-Facet metamodels. I should create new table editors
too to use this new table model.
My question is the following :
In which file should we store the table ? Currently it is done in the .di, but it seems me that it would be better in the .notation or in a new file.
Best regards,
--
Vincent Lorenzo
01-69-08-17-24
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
DILS/LISE
Point Courrier n° 174
91 191 Gif sur Yvette CEDEX
Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel.
Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité du groupe Atos ne pourra être engagée quant au contenu de ce message. Bien
que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être engagée pour tout dommage résultant d'un virus transmis.
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting
from any virus transmitted.