Bug 313986

Comment 1 Ansgar Radermacher 2010-10-15 08:57:43 EDT

I am currently working on the support for model validation. I already implemented the invocation of the validation via the EMF validation framework, including a small manipulation that associates an entry -an error marker- with the .di instead of the .uml resource (which is not really true, but enables that
the Papyrus editor is invoked instead of the UML tree viewer) and shows the qualified name of the model element as its location.

The following consideration applys to a part of the problem: when the user double-clicks on a problem, the payrus editor should be activated and navigate to the appropriate place, i.e. select the element related to the problem in the model explorer (ideally also in a diagram, but the same element might be contained in multiple diagrams). From an implementation viewpoint, the workbench checks whether the editor supports the IGotoMarker interface and uses the contained gotoMarker operation to navigate to the right place. The IGotoMarker could be added to the CoreMultiDiagEditor (or its heir, the Papyrus editor). I understand that -whenever possible- changes to the editor core should be minimal and in particular not add additional dependencies. The first problem is thus to locate the ModelExplorer for which I currently use the following code which is probably not the best way since it adds an implicit dependency (the ID of the model explorer):

IWorkbench wb = PlatformUI.getWorkbench();
IWorkbenchPage page = wb.getActiveWorkbenchWindow().getActivePage();
for(IViewReference view : page.getViewReferences()) {
   
if(view.getId().equals("org.eclipse.papyrus.modelexplorer.modelexplorer")) {
       ...
    }
}

I also added support for the IGotoMarker interface the ModelExplorer,
more specifically the ModelExplorerPageBookView. The 2nd problem is
howto set the selection of the model explorer. A simple setSelection
does not work, since I need to pass the wrapping ModelElementItem
instead of the contained eObject (in my case, a UML element). It's
perhaps not required to add the functionality, since the Modisco
ECoreBrowser already supports the IGotoMarker  (see e.g.
http://dev.eclipse.org/viewsvn/index.cgi/plugins/trunk/org.eclipse.gmt.modisco.infra.browser/src/org/eclipse/gmt/modisco/infra/browser/editors/EcoreBrowser.java?view=markup&root=Modeling_MODISCO&pathrev=2951)
and contains a browseTo method taking an EObject as parameter (this
function is actually used by the gotoMarker operation).  But since we
only use the model explorer view - if I understood it right - Modisco's
ECoreBrowser may not be available. Does anyone know if it's functions
could be used? A not-very-nice solution could be to copy the required
functionality, mainly the browseTo operation and the
findTreePathForElement(final EObject eObject) that the first function uses.

Comment 2 Ansgar Radermacher 2010-10-16 17:17:52 EDT

Created attachment 181039 [details]
First implementation of Decorators

The attachment shows the result of image decorators in the model explorer.

What is missing though is the use of tooltips that show the error message (not talking about hot-fixes yet ...).

Comment 3 Cedric Dumoulin 2010-10-22 05:49:52 EDT

You right that the PapyrusEditor should have no dependencies (even with an id) to any of its views or diagrams. This include of course the ModelExplorer.

I propose the following:
- lets have a IGotoMarkerNotifierService class that implements IGotoMarker. This service receive notifications from Eclipse (calls to {@link #gotoMarker(IMarker)})  and dispatch it to the currently active nested editors and to registered Listeners.
- lets the main Papyrus editor return the previous IGotoMarkerNotifierService when requested from IEditor.getAdapter(IGotoMarker)
- lets ModelExplorer listen to IGotoMarkerNotifierService. 
- Other views needing to be notified could also use this mechanism.

Comment 4 Ansgar Radermacher 2010-10-22 08:54:21 EDT

I commited code which adds error/warning decoration and a new "validate" command to the model explorer

Comment 5 Sébastien Gérard 2010-11-13 18:16:00 EST

Advice from Kenn Hussey:
"Basically, you just define rules XML, as you do with other rules, but use a language of "EMF". Rules defined this way must specify a class and method representing the EMF constraint; in your case, this would be the UMLValidator class (from UML2) and its various methods. More information can be found by looking at the classes in org.eclipse.emf.validation.internal.emfadapter."

Comment 6 Wojciech Trocki 2010-12-07 02:48:52 EST

(In reply to comment #4)
>  new "validate" command to the model explorer

Is this command based on emf validation framework ??

Old papyrus has emf validation based on selection occurred in editor. 
Is this function in plan?
Usage of this validation is described here:

http://www.linuxtopia.org/online_books/eclipse_documentation/eclipse_emf_validation_framework_developer_guide/topic/org.eclipse.emf.validation.doc/references/overview/eclipse_emf_validation_framework_listeners.html

Comment 7 Remi Schnekenburger 2012-02-13 09:57:57 EST

 done in version 0.8 of Papyrus