Bug 61367 - Callback D&D support
Callback D&D support
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Text
5.x
All All
: P1 (vote)
: 5.x
Assigned To: apireviews
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks: 53439
  Show dependency treegraph
 
Reported: 2005-07-25 15:39 UTC by Martin Roskanin
Modified: 2008-12-23 00:08 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments
diff of the api change (10.24 KB, text/plain)
2005-07-25 16:26 UTC, Martin Roskanin
Details
updated diff (7.32 KB, text/plain)
2005-07-28 08:57 UTC, Martin Roskanin
Details
Demo client usage of the API (5.16 KB, text/plain)
2005-07-28 08:58 UTC, Martin Roskanin
Details
Updated ActiveEditorDrop with javadoc of client usage (3.49 KB, text/plain)
2005-07-28 09:23 UTC, Martin Roskanin
Details
Please consider changes mentioned at previous comment (2.26 KB, text/plain)
2005-08-03 08:14 UTC, Martin Roskanin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Roskanin 2005-07-25 15:39:38 UTC
Usecase taken from nbFeature1143:

The editor needs to provide an SPI where various modules could plug in a "drop"
handler that would get invoked when a user drags&drops some object to the
editor. The handler should be able to handle the drop operation (e.g. open a
customization dialog, generate some text into the editor).

An example use-case is "code clips". The provider of code clips wants to offer
them in some kind of a clips palette. User should be able to d&d a particular
clip into the editor. A clip may be customizable (it is not just a plain text) -
a provider should be called as the clip is dropped to the editor so that it can
display a dialog for customizing a clip (e.g. in case of generating an EJB call
to allow user to select an EJB the code should invoke, etc.), after that the
provider should be able to generate code at the cursor position.
Comment 1 Martin Roskanin 2005-07-25 16:26:46 UTC
Created attachment 23273 [details]
diff of the api change
Comment 2 Martin Roskanin 2005-07-25 16:34:17 UTC
I attached corrected diff from issue #53439 with Mila's comments 1 and 2 as well
as Peter Z. comment, where CallbackTransferable's handleTransfer method should
return boolean. 
Diff uses delegating transfer handler,
so it is not necessary to copy jdk's dnd functionality like scrolling etc from
BasicTextUI. CallbackTransferable is the abstract class the client needs to
implement and return as a Transfereble. Abstract method handleTransfer(Component
targetComponent) will bring targetComponent to the dropStart initiator.
CallbackTransferable may work in delegating mode, so pass your already creaetd
transferables to constructor. Feel free to change the names of classes or
package location. There is an attached diff of client's side implementation in
the issue #53439. It demonstrates
addition of two DraggableButtons (that uses dnd callback functionality) to
editor toolbar.
Could you please review the suggested changes? Thanks.
Comment 3 Jaroslav Tulach 2005-07-27 14:29:26 UTC
I'd like to suggest small simplification in the API. Imho the 
CallbackTransferable should not implement Transferable as that a distracting 
implementation detail[1]. 
 
But then you need a better name as it is no longer transferable. I'll use 
ActiveEditorDrop, here, but you can choose whatever you like. 
 
However the name of the DataFlavor shall definitely change. I am not english 
speaker, but calling something FAKE_*_FLAVOR does not give me much trust in 
the API.  
 
[1] Here would be the API: 
 
package org.openide.text; 
interface ActiveEditorDrop { 
  public static final DataFlavor FLAVOR; 
  public void handleTransfer(...); 
} 
 
And in the javadoc of the class shall be sample usage: 
 
class MyDrop extends StringSelection implements ActiveEditorDrop { 
  public boolean isFlavorSupported (DataFlavor f) { 
    return super.isFlavorSupported(f) || FLAVOR == f; 
  } 
  // blablabla... 
} 
 
this imho does not change the implementation at all, keep the original spirit 
and clearly separates the Transferable and ActiveEditorDrop from each other as 
they seem really indepent. 
Comment 4 Martin Roskanin 2005-07-28 08:56:08 UTC
Yes, it sounds reasonable. Thanks for the review. I did only one minor
modification - method handleTransfer should return boolean.

I will attach updated diff, as well as new client usage demo.
Comment 5 Martin Roskanin 2005-07-28 08:57:25 UTC
Created attachment 23334 [details]
updated diff
Comment 6 Martin Roskanin 2005-07-28 08:58:36 UTC
Created attachment 23335 [details]
Demo client usage of the API
Comment 7 Martin Roskanin 2005-07-28 09:23:25 UTC
Created attachment 23337 [details]
Updated ActiveEditorDrop with javadoc of client usage
Comment 8 Jaroslav Tulach 2005-08-01 17:11:17 UTC
Fine with me, just do not forget @since, apichanges, arch document, etc. 
Comment 9 Martin Roskanin 2005-08-02 14:31:03 UTC
fixed in [maintrunk]

/cvs/openide/arch/arch-openide-editor.xml,v  <--  arch-openide-editor.xml
new revision: 1.23; previous revision: 1.22

/cvs/openide/text/apichanges.xml,v  <--  apichanges.xml
new revision: 1.7; previous revision: 1.6

/cvs/openide/text/manifest.mf,v  <--  manifest.mf
new revision: 1.7; previous revision: 1.6

/cvs/openide/text/src/org/openide/text/ActiveEditorDrop.java,v  <-- 
ActiveEditorDrop.java
initial revision: 1.1

/cvs/openide/text/src/org/openide/text/QuietEditorPane.java,v  <-- 
QuietEditorPane.java
new revision: 1.2; previous revision: 1.1
Comment 10 Martin Roskanin 2005-08-03 07:45:13 UTC
Documentation was modified. Link to undocumented QuietEditorPane was removed
from documentation and apichanges. 

/cvs/openide/text/apichanges.xml,v  <--  apichanges.xml
new revision: 1.8; previous revision: 1.7

/cvs/openide/text/src/org/openide/text/ActiveEditorDrop.java,v  <-- 
ActiveEditorDrop.java
new revision: 1.2; previous revision: 1.1

I have found one minor correction to proposed and commited diff. A method
canImport (of DelegatingTransferHandler in QuietEditorPane) could return true if
there is a ActiveEditorDrop.FLAVOR in transferFlavors. After this client doesn't
need to extend StringSelection and importData is called.
Comment 11 Martin Roskanin 2005-08-03 08:14:05 UTC
Created attachment 23435 [details]
Please consider changes mentioned at previous comment
Comment 12 Martin Roskanin 2005-08-09 14:36:23 UTC
changes integrated into [maintrunk]

/cvs/openide/text/apichanges.xml,v  <--  apichanges.xml
new revision: 1.9; previous revision: 1.8
done
Checking in manifest.mf;
/cvs/openide/text/manifest.mf,v  <--  manifest.mf
new revision: 1.8; previous revision: 1.7
done
Checking in src/org/openide/text/ActiveEditorDrop.java;
/cvs/openide/text/src/org/openide/text/ActiveEditorDrop.java,v  <-- 
ActiveEditorDrop.java
new revision: 1.3; previous revision: 1.2
done
Checking in src/org/openide/text/QuietEditorPane.java;
/cvs/openide/text/src/org/openide/text/QuietEditorPane.java,v  <-- 
QuietEditorPane.java
new revision: 1.3; previous revision: 1.2
done


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo