Community
Participate
Working Groups
It looks like diagram action handlers must implement SapphireDiagramActionHandler, which is a subclass of SapphireActionHandler. The subclass has two additional methods: canExecute and hasDoneModelChanges. These methods shouldn't be necessary. canExecute - In Sapphire action API this is handled by action handler enablement. A handler that cannot execute should place itself in disabled state. hasDoneModelChanges - The framework should not rely on the handler to tell it that. It can listen to model and parts changes to get the information it needs.
Bulk deferral of diagram-related items to the 0.5 release.
Per offline discussion, SapphireDiagramActionHandler class and its canExecute(Object) API should be eliminated. The DND usecases that gave rise to it should now be handled via a service rather than an action. The service API will allow for richer interaction necessary to support DND. Let's call the new service DragAndDropService and put it in the root org.eclipse.sapphire.ui package as I expect it to be useful outside of diagram editor in the future.
DragAndDrop Service has been implemented. SapphireDiagramActionHandler class has been eliminated. I also added a note in the 0.5 migration guide.
The format of the entry in the migration guide needs to be revised to match "before and after" format used elsewhere in the doc. Show a drop action handler with registration in before. Show service implementation with registration in after. Show another random action implementing SapphireDiagramActionHandler in before. Show it implementing action handler class directly in after. An entry for DragAndDropService is needed in the services document. I've been slowly working on reducing verbosity of key API in Sapphire. Particularly methods. Let's see if we can tighten up DragAndDropService... getDroppedObject() -> object() getDropPosition() -> position() canDrop() -> droppable() handleDrop() -> drop() Should canDrop/droppable take DropContext? I am thinking of the case where a drop is acceptable only in some places...
In MapDropService, shouldn't canDrop check if obj is an IFile?
Sapphire.Drop action is still defined in the extensions file.
The issues raised in comment 4, 5, and 6 have been addressed.
What about DiagramRenderingContext? It appears that its method getCurrentMouseLocation(), setCurrentMouseLocation(), getObject() and setObject() were all for previous method of dnd support...
Also, what are the semantics of the return value of the drop method?
> Also, what are the semantics of the return value of the drop method? Looking at DndObjectCommand, the returned object isn't used. Should drop() method be void instead?
Issues raised in comment 8, 9, and 10 have been addressed.
Further improved doc content. Verified. Closing.
