United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4830695 Require ability to add data import ability on top of existing TransferHandler
JDK-4830695 : Require ability to add data import ability on top of existing TransferHandler

Details
Type:
Enhancement
Submit Date:
2003-03-11
Status:
Open
Updated Date:
2014-03-11
Project Name:
JDK
Resolved Date:
Component:
client-libs
OS:
generic
Sub-Component:
javax.swing
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
1.4.0
Targeted Versions:
5.0-pool

Related Reports

Sub Tasks

Description
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

                                    

Comments
EVALUATION

This is important. Targeting to dolphin.
                                     
2006-06-09
EVALUATION

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

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
                                     
2008-10-16
EVALUATION

Also attached is a test of this Importer idea, file TopLevelTransferHandler.java
                                     
2008-10-16



Hardware and Software, Engineered to Work Together