Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 348672

Summary:	[diagram] Eliminate SapphireDiagramActionHandler class
Product:	z_Archived	Reporter:	Konstantin Komissarchik <konstantin>
Component:	Sapphire	Assignee:	Shenxue Zhou <shenxue.zhou>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Konstantin Komissarchik

2011-06-07 22:36:16 EDT

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.

Comment 1 Konstantin Komissarchik

2011-11-02 22:10:06 EDT

Bulk deferral of diagram-related items to the 0.5 release.

Comment 2 Konstantin Komissarchik

2012-04-06 17:57:41 EDT

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.

Comment 3 Shenxue Zhou

2012-05-23 12:45:37 EDT

DragAndDrop Service has been implemented. SapphireDiagramActionHandler class has been eliminated.

I also added a note in the 0.5 migration guide.

Comment 4 Konstantin Komissarchik

2012-05-23 15:44:49 EDT

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...

Comment 5 Konstantin Komissarchik

2012-05-23 15:48:08 EDT

In MapDropService, shouldn't canDrop check if obj is an IFile?

Comment 6 Konstantin Komissarchik

2012-05-23 15:53:08 EDT

Sapphire.Drop action is still defined in the extensions file.

Comment 7 Shenxue Zhou

2012-05-24 12:36:40 EDT

The issues raised in comment 4, 5, and 6 have been addressed.

Comment 8 Konstantin Komissarchik

2012-05-25 11:20:37 EDT

What about DiagramRenderingContext? It appears that its method getCurrentMouseLocation(), setCurrentMouseLocation(), getObject() and setObject() were all for previous method of dnd support...

Comment 9 Konstantin Komissarchik

2012-05-25 11:22:48 EDT

Also, what are the semantics of the return value of the drop method?

Comment 10 Konstantin Komissarchik

2012-05-25 11:23:57 EDT

> 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?

Comment 11 Shenxue Zhou

2012-05-25 13:26:18 EDT

Issues raised in comment 8, 9, and 10 have been addressed.

Comment 12 Konstantin Komissarchik

2012-05-25 17:53:45 EDT

Further improved doc content. Verified. Closing.