|
|
(One intermediate revision by one other user not shown) |
Line 1: |
Line 1: |
− | = Papyrus Struture <br> =
| + | This page must be destroyed. |
− | | + | |
− | will be done...
| + | |
− | | + | |
− | = Model Explorer: Internal drag and drop<br> =
| + | |
− | | + | |
− | This documentation explains the drag and drag from the model explorer to the model explorer.<br> | + | |
− | | + | |
− | === <br>Architecture<br> ===
| + | |
− | | + | |
− | The drag and drop is done thanks to the class ''org.eclipse.papyrus.modelexplorer.dnd.CommonDropAdapterAssistant''.
| + | |
− | | + | |
− | This class is referenced into the eclipse framework by using the extension point org.eclipse.ui.navigator.navigatorContent<br>
| + | |
− | | + | |
− | http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_ui_navigator_navigatorContent.html<br><br>It contains an attribute drop assistant. See the following example:<br>
| + | |
− | <pre><dropAssistant
| + | |
− | class="org.eclipse.papyrus.modelexplorer.dnd.CommonDropAdapterAssistant"
| + | |
− | id="org.eclipse.papyrus.modelexplorer.dnd.CommonDropAdapterAssistant">
| + | |
− | <possibleDropTargets>
| + | |
− | <or>
| + | |
− | <instanceof
| + | |
− | value="org.eclipse.gmf.runtime.notation.impl.DiagramImpl">
| + | |
− | </instanceof>
| + | |
− | <adapt
| + | |
− | type="org.eclipse.emf.ecore.EObject">
| + | |
− | </adapt>
| + | |
− | </or></possibleDropTargets>
| + | |
− | </dropAssistant></pre>
| + | |
− | To do the concrete drop, the following method has to be implemented:<br>
| + | |
− | <pre>public abstract IStatus handleDrop(CommonDropAdapter aDropAdapter,DropTargetEvent aDropTargetEvent, Object aTarget);</pre>
| + | |
− | <br>
| + | |
− | | + | |
− | In the subclass, the handleDrop method asks and executes a command. I separate the problem of construction of the commands of its execution.<br>
| + | |
− | | + | |
− | The creation of the command is done into the method getDrop()<br>
| + | |
− | | + | |
− | There are several cases of the drop event:<br>
| + | |
− | | + | |
− | *'''LOCATION_BEFORE'''
| + | |
− | | + | |
− | The mouse is placed just before an element
| + | |
− | | + | |
− | *'''LOCATION_AFTER'''
| + | |
− | | + | |
− | The mouse is placed just after an element
| + | |
− | | + | |
− | *'''LOCATION_ON'''
| + | |
− | | + | |
− | The mouse is placed on an element
| + | |
− | | + | |
− | <br>
| + | |
− | | + | |
− | The first two events are changments of order, we call the getChangeOrder in charge of building orders to rearrange the elements<br>For Location_on, this is a change of container, we call the method getDropIntoCommand in charge of creating the command to change container.
| + | |
− | | + | |
− | ==== <br>DropInto<br> ====
| + | |
− | | + | |
− | The operation is quite simple: It is to create a query such as '''MoveRequest''' with child elements. If a child is a diagram, it requires a specific command to change the parent of the diagram.
| + | |
− | | + | |
− | <br>
| + | |
− | | + | |
− | ==== getChangeOrder<br> ====
| + | |
− | | + | |
− | This algorithm is more complicated. If we move the elements before or after another, there may be changes in container. It is therefore essential to create a '''MoveRequest '''in order to ensure semantics and graphic consistency thanks to the Edit Service.
| + | |
− | | + | |
− | For this we test the first selected item if the list that moves. We test if there is a change of parent. If it is, a MoveRequest with all the children will be built and a move command is executed.
| + | |
− | | + | |
− | Since then we specify the position of the (LOCATION_AFTER, LOCATION_BEFORE) you have to build a request such '''SetRequest'''. The collection of future collection is calculated (location of children in the future collection)<br>All command are inside a commpound command in order to ensure a atomic do, undo , redo.<br>
| + | |
− | | + | |
− | <br>
| + | |
This page must be destroyed.