Skip to main content
Jump to: navigation, search

Difference between revisions of "Papyrus/Papyrus Developer Guide/How To Code Examples"

m (Papyrus Editors: Grammar edit.)
 
(22 intermediate revisions by 9 users not shown)
Line 3: Line 3:
 
This section contains code examples related to the 'core'  
 
This section contains code examples related to the 'core'  
  
=== How to get the ServiceRegistry ===
+
=== How to get the ServicesRegistry ===
  
 
The ServiceRegistry is a central point in Papyrus. It allows to get nearly all objects or services used by papyrus.  
 
The ServiceRegistry is a central point in Papyrus. It allows to get nearly all objects or services used by papyrus.  
  
 
There is one and only one ServiceRegistry for each Papyrus Editor.  
 
There is one and only one ServiceRegistry for each Papyrus Editor.  
 +
 +
  import org.eclipse.papyrus.infra.core.services.ServicesRegistry;
  
 
When you create a Diagram or a Service, Papyrus always provide the ServiceRegistry as an argument. You usually need to store it in a way you could easily retrieve it.  
 
When you create a Diagram or a Service, Papyrus always provide the ServiceRegistry as an argument. You usually need to store it in a way you could easily retrieve it.  
  
  import org.eclipse.papyrus.core.services.ServicesRegistry;
+
There are several ways to find the ServicesRegistry, depending on the objects you have at your disposal.  
  
If you are implementaing a Command Handler, you can get the ServiceRegistry of the currently active Papyrus editor like that:  
+
If you have the Papyrus main editor part ('''IEditorPart'''):  
  
    ServicesRegistry serviceRegistry = ServiceUtilsForActionHandlers.getInstance().getServiceRegistry();
+
  IEditorPart editorPart = getIEditorPart() // The Papyrus editor, not a nested editorPart
 +
  ServicesRegistry serviceRegistry = (ServicesRegistry)editor.getAdapter(ServicesRegistry.class);
  
If you are in a GMF related stuff and you have the IDiagramEditDomain :  
+
If you are in a '''GMF''' related stuff and you have the '''IDiagramEditDomain''' :  
  
 
     IDiagramEditDomain domain = getIDiagramEditingDomain(); //  
 
     IDiagramEditDomain domain = getIDiagramEditingDomain(); //  
 
     ServicesRegistry serviceRegistry = ServiceUtilsForGMF.getInstance().getServiceRegistry(domain);
 
     ServicesRegistry serviceRegistry = ServiceUtilsForGMF.getInstance().getServiceRegistry(domain);
  
If you have the Papyrus main editor part (IEditorPart):  
+
If you have an '''EObject''' (UML Element, Diagram, ...) attached to one Papyrus model:
  
  IEditorPart editorPart = getIEditorPart() // The Papyrus editor, not a nested editorPart
+
    EObject eobject = ....;
  ServicesRegistry serviceRegistry = (ServicesRegistry)editor.getAdapter(ServicesRegistry.class);
+
    ServicesRegistry registry = ServiceUtilsForResource.getInstance().getServiceRegistry(eobject.eResource());
  
<br> See also 'Papyrus Cookbook/How to get a Papyrus Service or the ServiceRegistry'  
+
See also example in Git: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/examples/infra/org.eclipse.papyrus.example.infra.servicesregistry.retrieval
 +
 
 +
If you are implementing a '''Command Handler''', you can rely on the fact that the currently selected editor is a Papyrus one. In this case, and only in this case, you can get the ServiceRegistry of the currently active Papyrus editor like that:
 +
 
 +
    ServicesRegistry serviceRegistry = ServiceUtilsForActionHandlers.getInstance().getServiceRegistry();
 +
 
 +
 
 +
 
 +
 
 +
 
 +
<br> See also 'Papyrus Cookbook/How to get a Papyrus Service or the ServiceRegistry'
  
 
=== How to get a Well Known Service  ===
 
=== How to get a Well Known Service  ===
Line 33: Line 46:
 
Papyrus has some well known services that can be easily retrieved. To get one of these services, you should use one of the XxxServiceUtils class. You should use the right ServiceUtils class, according to what kind of object you have at disposal. Use one of the following:  
 
Papyrus has some well known services that can be easily retrieved. To get one of these services, you should use one of the XxxServiceUtils class. You should use the right ServiceUtils class, according to what kind of object you have at disposal. Use one of the following:  
  
*<pre>org.eclipse.papyrus.core.utils.ServiceUtils</pre>  
+
*When you have the instance of the ServiceRegistry
**When you have the instance of the ServiceRegistry
+
**<pre>org.eclipse.papyrus.core.utils.ServiceUtils</pre>
*<pre>org.eclipse.papyrus.diagram.common.util.ServiceUtilsForGMF
+
 
 +
*When you have a GMF EditPart
 +
*When you have a GMF EditPolicies
 +
**<pre>org.eclipse.papyrus.diagram.common.util.ServiceUtilsForGMF
 
</pre>
 
</pre>
  
**When you have a GMF EditPart
+
*When you have an EObject, a Resource or a ResourceSet
**When you have a GMF EditPolicies
+
**<pre>org.eclipse.papyrus.infra.emf.utils.ServiceUtilsForResource
*<pre>org.eclipse.papyrus.core.utils.ServiceUtilsForActionHandlers
+
 
</pre>
 
</pre>
  
**from action handlers acting on the current active editor. This is the case for eclipse.ui.handler and similar code.
+
*from action handlers acting on the current active editor (and only in this case).This is the case for eclipse.ui.handler and similar code.
 +
 
 +
**<pre>org.eclipse.papyrus.core.utils.ServiceUtilsForActionHandlers
 +
</pre>
  
Examples - From the ServiceRegistry:<br>  
+
<br> Examples - From the ServiceRegistry:<br>  
 
<pre>  ServicesRegistry serviceRegistry = getServiceRegistry(); // see How to get the ServiceRegistry
 
<pre>  ServicesRegistry serviceRegistry = getServiceRegistry(); // see How to get the ServiceRegistry
 
   TransactionalEditingDomain editingDomain = ServiceUtils.getInstance().getTransactionalEditingDomain(serviceRegistry);
 
   TransactionalEditingDomain editingDomain = ServiceUtils.getInstance().getTransactionalEditingDomain(serviceRegistry);
 
</pre>  
 
</pre>  
 +
<br> Examples - From an EObject:<br>
 +
<pre>  EObject eobject = ...; // You should know how to get your EObject :-)
 +
  ModelSet modelSet = ServiceUtilsForResource.getInstance().getModelSet(eobject.eResource());
 +
</pre>
 +
 +
 
Examples - From an Handler (and only from handler, check javadoc):<br>  
 
Examples - From an Handler (and only from handler, check javadoc):<br>  
  
 
   TransactionalEditingDomain editingDomain = ServiceUtilsForActionHandlers.getInstance().getTransactionalEditingDomain();
 
   TransactionalEditingDomain editingDomain = ServiceUtilsForActionHandlers.getInstance().getTransactionalEditingDomain();
 
+
  
 
==== Well Known Services  ====
 
==== Well Known Services  ====
Line 85: Line 109:
  
 
<br>  
 
<br>  
 +
 +
=== How to be notified of page lifecycle  ===
 +
 +
The SashWindows system send events during the life cycle of a page (i.e. the nested editor). It is possible to listen on these events.
 +
 +
Your listener should implement the following interface:<br>
 +
<pre>org.eclipse.papyrus.sasheditor.editor.IPageLifeCycleEventsListener
 +
</pre>
 +
Then you need to register your listener to the sashWindowContainer:<br>
 +
 +
<br>
 +
 +
    ISashWindowsContainer container = getISashWindowsContainer(); // see&nbsp; How to get the ISashWindowsContainer;
 +
    IPageLifeCycleEventsListener listener = ... // Get your listener
 +
    container.addPageLifeCycleListener(listener);
 +
 +
<br>
  
 
=== How to get the ISashWindowsContainer<br>  ===
 
=== How to get the ISashWindowsContainer<br>  ===
Line 192: Line 233:
  
 
When you ask the current selection, you get the selected Graphical Object. Often, you really want the underlying domain object (i.e. the UML object).
 
When you ask the current selection, you get the selected Graphical Object. Often, you really want the underlying domain object (i.e. the UML object).
As there is several graphical technology used to in Papyrus (GMF, GEF, Common Navigator ...), you shouldn't test for the type of the selected object, but rather you should "adapt" it to the requested type.
+
As there is several graphical technology used in Papyrus (GMF, GEF, Common Navigator ...), you shouldn't test for the type of the selected object, but rather you should "adapt" it to the requested type.
 +
 
 +
  Object obj = ... // The Graphical Object
 +
  if( obj instanceof IAdaptable ) {
 +
    NamedElement ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
 +
    // Adapt object to NamedElement
 +
    NamedElement ele = null;
 +
    if( obj instanceof IAdaptable ) {
 +
      ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
 +
    }
 +
    if( ele == null) {
 +
      ele = (NamedElement)Platform.getAdapterManager().getAdapter(obj, NamedElement.class);
 +
    }
 +
  }
  
 
The following method get the list of selections, adapt each selected element to get its underlying UML type, and return a list of the found UML types.
 
The following method get the list of selections, adapt each selected element to get its underlying UML type, and return a list of the found UML types.
Line 208: Line 262:
 
   for( Object obj : selections) {
 
   for( Object obj : selections) {
 
     // Adapt object to NamedElement
 
     // Adapt object to NamedElement
 +
    NamedElement ele = null;
 
     if( obj instanceof IAdaptable ) {
 
     if( obj instanceof IAdaptable ) {
       NamedElement ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
+
       ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
       if(ele != null) {
+
    }
        results.add(ele);
+
    if(ele == null) {
      }
+
       ele = (NamedElement)Platform.getAdapterManager().getAdapter(obj, NamedElement.class);
 +
    }
 +
    if(ele != null) {
 +
      results.add(ele);
 
     }
 
     }
 
   }
 
   }
Line 218: Line 276:
 
}
 
}
 
</pre>
 
</pre>
 +
 +
=== How to create external label which can be set invisible  ===
 +
When creating external label you want them to be usable by the framework of MDT Papyrus which handle label visibility.
 +
With figure such as WrappingLabel there is a little problem. This consider containing point even if it is invisible.
 +
However the correct behaviour for such element is that invisible element should be consider not usable by the diagram.
 +
I would advice you from now to use org.eclipse.papyrus.diagram.common.figure.node.PapyrusWrappingLabel instead normal WrappingLabel figure.
 +
This figure implement the following method:
 +
<pre>
 +
    @Override
 +
    public boolean containsPoint(int x, int y) {
 +
        if (isVisible()){
 +
            return super.containsPoint(x, y);           
 +
        }
 +
        return false;
 +
    }
 +
 +
</pre>
 +
If you want to use other figure for externals labels you should make sure the method containsPoint of this method return false if the figure is invisible.
  
 
== Diagram Examples  ==
 
== Diagram Examples  ==
Line 225: Line 301:
 
=== How to develop my own UML diagram<br>  ===
 
=== How to develop my own UML diagram<br>  ===
  
Papyrus allow to add new kind of UML diagrams. A plugin example with a doc can be found in the SVN:<br>  
+
Papyrus allow to add new kind of UML diagrams. A plugin example with a doc can be found in the Git :<br>  
  
*http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/examples/others/org.eclipse.papyrus.example.diagram.simplediagram<br>
+
*http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/examples/others/org.eclipse.papyrus.example.diagram.simplediagram<br>
  
[To be completed]  
+
[To be completed]
 +
 
 +
=== Compartment without Scrollbar  ===
 +
 
 +
*this recipe is explained here [[Papyrus Developer Guide/NoScrollbar]]
 +
 
 +
=== Create graphical elements programmatically  ===
 +
 
 +
See [[Papyrus Developer Guide/CreateProgrammatically]]
 +
 
 +
== Editing Domain and Command ==
 +
[[Papyrus/Papyrus_Developer_Guide/Editing_Domains_and_Commands]]
  
 
== More Examples<br>  ==
 
== More Examples<br>  ==
  
 
*The following folder contains more examples (sometime deprecated).  
 
*The following folder contains more examples (sometime deprecated).  
**http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/doc/DevelopperDocuments/cookbook/  
+
**http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/doc/DevelopperDocuments/cookbook/
*Check the cookbook ([http://dev.eclipse.org/svnroot/modeling/org.eclipse.mdt.papyrus/trunk/doc/DevelopperDocuments/cookbook/PapyrusCookBook.odt PapyrusCookBook.odt])
+
*Check the cookbook ([http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/doc/DevelopperDocuments/cookbook/PapyrusCookBook.odt PapyrusCookBook.odt])
 +
 
 +
=== Papyrus ServiceRegistry  ===
 +
 
 +
The ServiceRegistry is one of the main Papyrus component. The idea is that each Papyrus feature should be a service registered to the ServiceRegistry.
 +
 
 +
The ServiceRegistry should be accessible from any code. It allows to retrieve the components you need to perform your task. <br> A new implementation of the ServiceRegistry is submitted. The new ServiceRegistry is discussed here [[Papyrus Developer Guide/Service Registry]]
 +
 
 +
=== Manage Decorators On Papyrus ===
 +
Papyrus provide services in order To manage decoration on Edit Parts from graphical editor or on icons from model explorer. An application example are describe here: [[Manage Decorators On Papyrus]]
 +
 
 +
=== Papyrus Log  ===
 +
 
 +
*Papyrus Log is explained here [[Papyrus Developer Guide/Papyrus Log]]
 +
 
 +
=== Papyrus Editors  ===
 +
 
 +
Currently Papyrus provides two kinds of editors: Diagrams and Table. How to add your own editor type is explained here: [[Papyrus Developper Guide/How to - Add your own editor in Papyrus]]
 +
 
 +
=== JUnit Tests  ===
 +
 
 +
* How to add JUnit tests to the build: [[Papyrus Developer Guide/Add JUnit Test Bundle]]
 +
* A code generation framework has been developed to automatically generate JUnit tests for GMF-based editors:  [[Papyrus Developer Guide/Automatic Test Generation for Diagram Editors]]
 +
* Useful utilities for JUnit tests:  [[Papyrus Developer Guide/JUnit Test Framework]]
 +
 
 +
=== Papyrus Table Developer Documentation  ===
 +
* The documentation for developers is available here [[Table Developer Documentation]]
 +
 
 +
=== Papyrus Diagram Developer Documentation  ===
 +
* The documentation for developpers is available here [[Diagram Developer Documentation]]
 +
 
 +
=== Papyrus Embedded Editors Documentation  ===
 +
* The documentation for developers is available here [[Embedded Editors Developer Documentation]]

Latest revision as of 15:15, 9 July 2020

Core Examples

This section contains code examples related to the 'core'

How to get the ServicesRegistry

The ServiceRegistry is a central point in Papyrus. It allows to get nearly all objects or services used by papyrus.

There is one and only one ServiceRegistry for each Papyrus Editor.

 import org.eclipse.papyrus.infra.core.services.ServicesRegistry;

When you create a Diagram or a Service, Papyrus always provide the ServiceRegistry as an argument. You usually need to store it in a way you could easily retrieve it.

There are several ways to find the ServicesRegistry, depending on the objects you have at your disposal.

If you have the Papyrus main editor part (IEditorPart):

 IEditorPart editorPart = getIEditorPart() // The Papyrus editor, not a nested editorPart
 ServicesRegistry serviceRegistry = (ServicesRegistry)editor.getAdapter(ServicesRegistry.class);

If you are in a GMF related stuff and you have the IDiagramEditDomain :

   IDiagramEditDomain domain = getIDiagramEditingDomain(); // 
   ServicesRegistry serviceRegistry = ServiceUtilsForGMF.getInstance().getServiceRegistry(domain);

If you have an EObject (UML Element, Diagram, ...) attached to one Papyrus model:

   EObject eobject = ....;
   ServicesRegistry registry = ServiceUtilsForResource.getInstance().getServiceRegistry(eobject.eResource());

See also example in Git: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/tree/examples/infra/org.eclipse.papyrus.example.infra.servicesregistry.retrieval

If you are implementing a Command Handler, you can rely on the fact that the currently selected editor is a Papyrus one. In this case, and only in this case, you can get the ServiceRegistry of the currently active Papyrus editor like that:

   ServicesRegistry serviceRegistry = ServiceUtilsForActionHandlers.getInstance().getServiceRegistry();




See also 'Papyrus Cookbook/How to get a Papyrus Service or the ServiceRegistry'

How to get a Well Known Service

Papyrus has some well known services that can be easily retrieved. To get one of these services, you should use one of the XxxServiceUtils class. You should use the right ServiceUtils class, according to what kind of object you have at disposal. Use one of the following:

  • When you have the instance of the ServiceRegistry
    • org.eclipse.papyrus.core.utils.ServiceUtils
  • When you have a GMF EditPart
  • When you have a GMF EditPolicies
    • org.eclipse.papyrus.diagram.common.util.ServiceUtilsForGMF
  • When you have an EObject, a Resource or a ResourceSet
    • org.eclipse.papyrus.infra.emf.utils.ServiceUtilsForResource
  • from action handlers acting on the current active editor (and only in this case).This is the case for eclipse.ui.handler and similar code.
    • org.eclipse.papyrus.core.utils.ServiceUtilsForActionHandlers


Examples - From the ServiceRegistry:

  ServicesRegistry serviceRegistry = getServiceRegistry(); // see How to get the ServiceRegistry
  TransactionalEditingDomain editingDomain = ServiceUtils.getInstance().getTransactionalEditingDomain(serviceRegistry);


Examples - From an EObject:

  EObject eobject = ...; // You should know how to get your EObject :-)
  ModelSet modelSet = ServiceUtilsForResource.getInstance().getModelSet(eobject.eResource());


Examples - From an Handler (and only from handler, check javadoc):

 TransactionalEditingDomain editingDomain = ServiceUtilsForActionHandlers.getInstance().getTransactionalEditingDomain();

Well Known Services

  • ServiceRegistry
    • Allow to get any service by its name
  • ModelSet
    • Service allowing to get API to access the underlying 'Models' used by Papyrus
  • TransactionalEditingDomain
    • EMF object used to perform transactions on the Models
  • IPageMngr
    • Service used to open, close, add pages in the SashWindow
  • ISashWindowsContainer
    • This service manage the nested editors.
  • ILifeCycleEventsProvider
    • Service providing events when a 'save' actions is required by the user.

How to be notified when active page change

The SashWindows system send events when the current active page change (i.e. the nested editor). It is possible to listen on this event.

Your listener should implement the following interface:

org.eclipse.papyrus.sasheditor.editor.IPageChangedListener

Then you need to register your listener to the sashWindowContainer:


   ISashWindowsContainer container = getISashWindowsContainer(); // see  How to get the ISashWindowsContainer;
   IPageChangedListener listener = ... // Get your listener
   container.addPageChangedListener(listener);


How to be notified of page lifecycle

The SashWindows system send events during the life cycle of a page (i.e. the nested editor). It is possible to listen on these events.

Your listener should implement the following interface:

org.eclipse.papyrus.sasheditor.editor.IPageLifeCycleEventsListener

Then you need to register your listener to the sashWindowContainer:


   ISashWindowsContainer container = getISashWindowsContainer(); // see  How to get the ISashWindowsContainer;
   IPageLifeCycleEventsListener listener = ... // Get your listener
   container.addPageLifeCycleListener(listener);


How to get the ISashWindowsContainer

The ISashWindowContainer allows to listen on page changed events, or to refresh the windows. There is one ISashWindowsContainer for each Papyrus editor.

It is possible to get it in different ways:

From the ServiceRegistry:

  ServicesRegistry serviceRegistry = getServiceRegistry(); // see How to get the ServiceRegistry
  ISashWindowsContainer container = ServiceUtils.getInstance().getISashWindowsContainer(serviceRegistry);

From an Handler (and only from handler, check javadoc):

 ISashWindowsContainer container = ServiceUtilsForActionHandlers.getInstance().getISashWindowsContainer();
 

From the Papyrus IEditorPart ():

	
        IEditorPart editorPart = getIEditorPart() // The Papyrus editor, not a nested editorPart
        ISashWindowsContainer container = (ISashWindowsContainer)editorPart.getAdapter(ISashWindowsContainer.class);

How to get the currently active nested editor

You can get the nested editor that is currently active from the ISashWindowContainer.

First, get the ISashWindowsContainer (see ).

Second get the Active nested editor:

        ISashWindowsContainer container = getISashWindowsContainer(); // see  How to get the ISashWindowsContainer;
        IEditorPart activeEditor = container.getActiveEditor();

How to get the list of visible nested editors

How to get the list of IEditorPart for the Opened Diagrams

A visible nested editor is one that is visible from the user. There can be several nested editors visible at one time. You can get the list of visible editors:

 ISashWindowsContainer container = getISashWindowsContainer(); // see  How to get the ISashWindowsContainer;
 List<IEditorPart> visibleEditors = container .getVisibleIEditorParts();

How to get the IPageMngr

The IPageMngr class allows to open, close, page in the sash window system. A page is generally a diagram. The IPageMngr also allows to list existing pages, or to check if a page is open. See the javadoc for more.

The IpageMngr can be retrieved from the ServiceRegistry:

 
 ServicesRegistry serviceRegistry = getServiceRegistry(); // see How to get the ServiceRegistry
 IPageMngr pageMngr = ServiceUtils.getInstance().getIPageMngr(serviceRegistry);

How to open/close a nested editors

Nested editors can be opened and closed programatically.

For that, you need to have the 'diagram identifier': this is the object that you provide when you open the diagram. The ID. For GMF diagrams, this is usually the notation.Diagram element used as the root of the diagram.

An instance of the class IPageMngr is used to open or close a diagram:

 
  IPageMngr pageMngr = getIPageMngr(); // see How to get the IPageMngr
 
  // Open all closed diagrams
  for( Object id : pageMngr.allPages() {
    if( ! pageMngr.isOpened(id)
      pageMngr.open(id);
  } 
  
  // Close all opened diagrams
  for( Object id : pageMngr.allPages() {
    if( pageMngr.isOpened(id)
      pageMngr.close(id);
  } 
  

How to Get the Current Selection from Java code

You can get the current selection inside the active nested editor by using the usual Eclipse way:

 IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
 ISelection selection = page.getActiveEditor().getSite().getSelectionProvider().getSelection();

This will give you a Selection object containing a collection of Graphical Objects (ex: GMF class, Common Navigator class ...). If you want to get the associated "Domain" object (i.e. the UML objects), you should adapt your Graphical Object to a UML one (see #How to adapt a Graphical Object to underlying Domain (UML)). See the two next methods for example.


This first method return a list of selected elements:

 
  /**
   * Lookup selected objects in UI. 
   * @return
   */
  protected List<Object> lookupSelectedElements() {
    IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
    ISelection selection = page.getSelection();
    if(selection instanceof IStructuredSelection) {
	IStructuredSelection structuredSelection = (IStructuredSelection)selection;
	return structuredSelection.toList();
      }
      else if( selection instanceof TreeSelection) {
	TreeSelection treeSelection = (TreeSelection)selection;
	return treeSelection.toList();
      }
    return null;
}

How to adapt a Graphical Object to underlying Domain (UML)

When you ask the current selection, you get the selected Graphical Object. Often, you really want the underlying domain object (i.e. the UML object). As there is several graphical technology used in Papyrus (GMF, GEF, Common Navigator ...), you shouldn't test for the type of the selected object, but rather you should "adapt" it to the requested type.

 Object obj = ... // The Graphical Object
 if( obj instanceof IAdaptable ) {
   NamedElement ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
   // Adapt object to NamedElement
   NamedElement ele = null;
   if( obj instanceof IAdaptable ) {
     ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
   }
   if( ele == null) {
     ele = (NamedElement)Platform.getAdapterManager().getAdapter(obj, NamedElement.class);
   }
 }

The following method get the list of selections, adapt each selected element to get its underlying UML type, and return a list of the found UML types.

/**
 * Return a list of selected domain (UML) elements.
 * @return
 */
protected List<NamedElement> getSelectedUmlObject() {
  List<Object> selections = lookupSelectedElements(); // see "How to Get the Current Selection from Java code"
		
  List<NamedElement> results = new ArrayList<NamedElement>();

  // create model with EList<EObject> objects
  for( Object obj : selections) {
    // Adapt object to NamedElement
    NamedElement ele = null;
    if( obj instanceof IAdaptable ) {
      ele = (NamedElement)((IAdaptable)obj).getAdapter(NamedElement.class);
    }
    if(ele == null) {
      ele = (NamedElement)Platform.getAdapterManager().getAdapter(obj, NamedElement.class);
    }				
    if(ele != null) {
      results.add(ele);
    }
  }
  return results;
}

How to create external label which can be set invisible

When creating external label you want them to be usable by the framework of MDT Papyrus which handle label visibility. With figure such as WrappingLabel there is a little problem. This consider containing point even if it is invisible. However the correct behaviour for such element is that invisible element should be consider not usable by the diagram. I would advice you from now to use org.eclipse.papyrus.diagram.common.figure.node.PapyrusWrappingLabel instead normal WrappingLabel figure. This figure implement the following method:

    @Override
    public boolean containsPoint(int x, int y) {
        if (isVisible()){
            return super.containsPoint(x, y);            
        }
        return false;
    }

If you want to use other figure for externals labels you should make sure the method containsPoint of this method return false if the figure is invisible.

Diagram Examples

This section contains code example related to diagrams.

How to develop my own UML diagram

Papyrus allow to add new kind of UML diagrams. A plugin example with a doc can be found in the Git :

[To be completed]

Compartment without Scrollbar

Create graphical elements programmatically

See Papyrus Developer Guide/CreateProgrammatically

Editing Domain and Command

Papyrus/Papyrus_Developer_Guide/Editing_Domains_and_Commands

More Examples

Papyrus ServiceRegistry

The ServiceRegistry is one of the main Papyrus component. The idea is that each Papyrus feature should be a service registered to the ServiceRegistry.

The ServiceRegistry should be accessible from any code. It allows to retrieve the components you need to perform your task.
A new implementation of the ServiceRegistry is submitted. The new ServiceRegistry is discussed here Papyrus Developer Guide/Service Registry

Manage Decorators On Papyrus

Papyrus provide services in order To manage decoration on Edit Parts from graphical editor or on icons from model explorer. An application example are describe here: Manage Decorators On Papyrus

Papyrus Log

Papyrus Editors

Currently Papyrus provides two kinds of editors: Diagrams and Table. How to add your own editor type is explained here: Papyrus Developper Guide/How to - Add your own editor in Papyrus

JUnit Tests

Papyrus Table Developer Documentation

Papyrus Diagram Developer Documentation

Papyrus Embedded Editors Documentation

Back to the top