Re: [mdt-papyrus.dev] Status of EMF Validation

[Vincent Hémery <vincent.hemery@xxxxxxxxxxxxxx>]

Hello Ansgar,

About the errors in the Problem view :

I think the best option is the (1) :
 - if the file is already opened with a di editor, try and select the 
element in the Model Explorer view, and a (not necessarily the only) 
corresponding edit part (if there is one).
 - in case the uml file is not being edited, it does not shock me that 
the uml file is opened instead of the Papyrus diagram, since the model 
itself is faulty.

I do not agree with you in (3), when you say that "nobody will use the 
problem view if there are more than a 20-30 errors". Based on my 
experience with Topcased, and with the activity diagram, when a diagram 
has too many errors, the first thing I do is look at the Problem view to 
see what kind of errors I have (different types or same error made 
several times).
Moreover, when error messages are long or not trivial, the Problem view 
provides a much more user-friendly visualisation than the tooltip (which 
may not fit completelly in the screen). Finally, the concerned element 
may even have no graphical representation at all.



About the error decorator for diagrams :

>     (1) In the model explorer, I add decorators to parents of 
elements that have an error, e.g. to a package if a contained class has 
errors.
> (text tooltip text indicates this). I don't know if it is a good idea 
to do the same on the diagrams.

I do not think either this is necessary to put a decorator on figures 
having a child in error. We do it in the model explorer view only 
because nodes are not expanded by default. But you can see all nodes one 
the diagram, hence I think it would only bring confusion.



About rules defined through the emf.validation.constraintProviders :

We absolutely have to check them. As far as I know, this is the best 
approach to introduce new rules, and the one used by gmf generated editors.
I do not fully understand whether you were unsuccessfull checking them 
or whether you are just not happy with the implementation you used ... 
Could you please clarify this point ?


Regards,
Vincent.


Le 06/11/2010 10:14, RADERMACHER Ansgar 206501 a écrit :
> Dear all,
>
> I just fixed a refresh problem (the code from the GMF templates installed a refresh listener per diagram type. But the listener had a diagram (instance) attribute which is used to obtain the editing domain. Thus, it failed once two models were opened the same time). Unfortunately, it implies that you have to regenerate the diagrams. Now, the main part of the ValidationDecorator support is in the generic class diagrams.common.providers.ValidationDecoratorsProviders.
>
> The current status of EMF validation is as follows:
> - error decorators are supported on all diagrams. A tooltip shows the error message(s)
> - error decorators are supported in the model explorer. A tooltip shows the error message. There are two inconsistencies between model explorer and diagrams.
>     (1) In the model explorer, I add decorators to parents of elements that have an error, e.g. to a package if a contained class has errors.
> (text tooltip text indicates this). I don't know if it is a good idea to do the same on the diagrams.
>    (2) The tooltip on a treeviewer (jface.viewers.CellLabelProvider) is just a string, thus the message text can not be prefixed by the appropriate icon (it's just a "-" sign) as the GMF viewers do. [well, I could add a single icon to the tooltip, but this would not be very useful for multiple messages].
> - A validation command is available in the context menu of the model explorer (I don't know why it does not appear on the diagrams)
>
> The error markers are registered with the .uml file, thus double clicking on these opens an editor registered for the UML extension. For testing, I registered Papyrus with the uml extension as well. It works out of the box, but is very problematic since it allows you to open two editors on the same resource.
> The options are to
> (1) if possbile manipulate the openEditor function to activate an existing editor opened on the di (uml), if the user double-clicks on the uml (di) file.
> (2) Register Papyrus only as an editor for .uml files
> (3) only register Papyrus for di files and don't care that the tree-based UML editor is opened when double-clicking on a problem, since nobody will use the problem view if there are more than a 20-30 errors (probably for different UML resources). My experience with Java is that I only relied on the error decorators, not on the problem view.
> (4) store error markers on the di file and re-enable the "hack" used before
>
> Another issue: there is a small problem with regard to the differences between EValidator + EMF Validation (see
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.emf.validation.doc/tutorials/validationAdapterTutorial.html): out of the box, user defined rules based on the extension point emf.validation.constraintProviders are not executed during validation. As described in the article, an EValidatorAdaptor is required and needs to be registered. Such an EvalidatorAdater already exists in MoDisco, but it is marked as internal (discouraged access).
>
> I currently use the following line to the Activator of the uml.modelexplorer to register this Adapter:
> EValidator.Registry.INSTANCE.put(UMLPackage.eINSTANCE, new EValidatorAdapter());
> @MoDisco experts: is this registration possible by a cleaner means?
>
> Best regards
>
> Ansgar

--


	*Hémery Vincent*
*Ingénieur - Atos Origin*
Telephone : +33 (0) 5 34 36 32 90
www.atosorigin.fr <http://www.atosorigin.fr>

Développement durable, anticipons pour notre avenir / Sustainability,
advance our future
P N'imprimez ce mail que si nécessaire / please consider your
environmental responsibility before printing this e-mail.
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 Origin ne pourra être recherché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
recherché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 Origin group
liability cannot be triggered for the message content. Although the
sender endeavours 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.