| Delegating Drag and Drop, bug 10146 [message #155] |
Thu, 17 April 2003 11:43  |
Eclipse User |
|
|
|
Originally posted by: knut_radloff.oti.com
http://bugs.eclipse.org/bugs/show_bug.cgi?id=10146
The following is quoted from the bug report. This should be of interest to anyone implementing drag and drop support in their
Eclipse plugins, or even in standalone SWT applications. Feedback is encouraged, especially from anyone who copied the JDT or GEF
DelegatingDragAdaper/DelegatingDropAdapter code.
Again, please note that the new classes are experimental in nature and may be removed in the future. Since the original request was
for Platform UI to adopt the delegating drag and drop support the platform-ui-dev mailing list would be the best place to discuss
this. I'm crossposting to platform.swt to get feedback from users of plain SWT drag and drop. Go to
http://www.eclipse.org/mail/index.html to subscribe to mailing lists.
Knut
"I released an experimental version of the delegating drag and drop support to
org.eclipse.jface.
The files are:
org.eclipse.jface.util.DelegatingDragAdapter
org.eclipse.jface.util.DelegatingDropAdapter
org.eclipse.jface.util.TransferDragSourceListener
org.eclipse.jface.util.TransferDropTargetListener
The two concepts/benefits of the delegating drag and drop are:
1) Allowing a 1:1 mapping between transfer type and listener.
The listener implementation depends on the transfer type. This is certainly
true for dragSetData and drop. In the Resource Navigator use case the
dragEnter, dragFinished and dragStart implementations vary depending on the
transfer type. The listener code will be greatly simplified if it can be
separated by transfer type.
The current SWT listener in DragSource/DropTarget does not allow for a clean
separation by transfer type.
2) Controlling enablement of listeners.
Drag listener enablement often depends on selection state. Based on the
selection some or all transfer types may not be valid. In the GEF use case
finer control over drop enablement is needed as well. Drop enablement may
change based in the drag operation and location.
The question is if SWT can provide more fine grained drag and drop listener
support.
Scenario 1) could be supported by adding API that allows setting a listener for
a specific transfer type. The code I released adds a method #getTransfer() to
the drag/drop listener interface for this purpose. There are other options.
Scenario 2) could be supported by adding a doit field to the dropTargetEvent.
The current code uses the dragStart doit field of the DragSourceEvent and adds
a method #isEnabled to the drop listener interface to determine enablement of a
particular listener.
Interested parties are encouraged to provide further input they may have,
including corrections and additions to the two scenarios I provide and the
changes to SWT that I suggest. Please verify that the SWT changes I suugest and
the preliminary code I released would be sufficient for your use cases."
|
|
|
| Suggestions on extension points on business logic [message #327129 is a reply to message #155] |
Thu, 10 April 2008 21:34  |
| Eclipse User |
|
|
|
Originally posted by: kathir.atc.tcs.com
Is it a good idea to implement Business Logics using extension points ,
extensions concept?
I am planning to develop a simple application platform to which
different applications will be plugged in. All the applications will have
the same perspectives and views but the business logic changes.
So i was thinking of creating a platform with all the perspectives and
views and give extension points to include the logic. Is this a good idea?
So when the application type changes, the perspective should behave as
per its logic defined through the extension point.
Is there any other better approach? Any help would be appreciated.
--
BR,
Kathir.
|
|
|
Powered by
FUDForum. Page generated in 0.03604 seconds
Home