In order to add custom data transfer support to a JComponent, a developer must write a custom TransferHandler and call setTransferHandler on the component. Swing's UI classes provide a default TransferHandler that does the most common thing for some of the components (import/export of text in text components for example).

One of the problems that we're seeing is that it is too difficult for developers to *add* handling of additional data flavors on top of the defaults provided by Swing. For example, if a developer wanted to customize a JTextField to accept drops of colors they would write a custom TransferHandler and set it using setTransferHandler. The problem is that this then wipes out the default support (import/export of text). In order to overcome this, the developer would need to *copy* a whole bunch of TransferHandler code from BasicTextUI.

Another approach that I've considered suggesting is to write a TransferHandler that can wrap an existing TransferHandler and delegate where necessary. This would allow the new TransferHandler to handle flavors that it recognizes and delegate the rest. The problem with this approach is that two methods that we'd need to delegate to (createTransferable and importDone) are protected.

We should find a way to allow developers to provide additional support without clobbering the default. Possibilities include:

- making createTransferable and importDone public to allow delegation
- moving the default TransferHandler implementations somewhere where they can be subclassed
- allowing multiple TransferHandlers

N/A

This is important. Targeting to dolphin.
Posted Date : 2006-06-09 18:22:55.0

Contribution forum : https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=14135
Posted Date : 2006-07-09 16:06:51.0

I prototyped an approach for this that I really like. That is, the ability to register an Importer class with a TransferHandler, to which importing can be delegated. Prototype is attached as TransferHandler_IMPORTERS.java
Posted Date : 2008-10-16 03:36:41.0

Also attached is a test of this Importer idea, file TopLevelTransferHandler.java
Posted Date : 2008-10-16 03:40:38.0

How does the protected scope of createTransferable and
importDone prevent the construction of composite
TransferHandlers?

Answer to coxcu's question:
The protected scope of those two methods prevents the 
approach where one TransferHandler wraps another. A 
TransferHandler subclass cannot invoke protected methods on 
instances of the TransferHandler class. This makes delegation 
impossible.

This may sound unintuitive, and it took me awhile to figure 
out what was wrong. I found the answer in the VM spec:

http://java.sun.com/docs/books/jls/second_edition/html/name
s.doc.html#62587

http://java.sun.com/docs/books/jls/second_edition/html/name
s.doc.html#36191

http://java.sun.com/docs/books/tutorial/java/javaOO/accessc
ontrol.html

I have an idea. I haven't tried it out yet but it goes 
something like this:
Subclass the TransfareHandler and provide a public API to 
these methods, then create a wrapper arround the subclass 
as proposed.

Subclassing TransferHandler works of course but what we want
to do is subclass an internal TransferHandler class which
inside the BasicTextUI.

Hwoever -if you only want to paste data from the clipboard
into the textcomponent (not copy or move data out fo the
component) the delegate approach seems to work fine as you
do not need to overwrite the protected methods.

Ive stumbled upon this problem as well And I dont see 
the problem of making those methods public, I doubt 
that any malicious code could be doing anything bad 
with the data it gets from the createTransferable() 
method. 

Ive fixed a workaround for this problem, through using 
the reflection API. This is not my preferred way of 
implementing but it is the only way to make it possible. 
This TransferHandler can take multiple handlers, and 
using the chain of responsibility to find out if the any of 
the added transfer handlers are capable of handling 
specific DataFlavors.

MultipleTransferHandler can be found at:
http://cvs.sourceforge.net/viewcvs.py/columba/frapuccin
o/src/java/org/frappucino/swing/MultipleTransferHandle
r.java
http://redsolo.blogspot.com/2004_03_01_redsolo_arch
ive.html#108004595020752861

Full java source describing the problem at:
http://forum.java.sun.com/thread.jsp?
forum=57&thread=506004