JDK-4830695 : Require ability to add data import ability on top of existing TransferHandler
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2003-03-11
  • Updated: 2017-05-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0-poolUnresolved
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 Also attached is a test of this Importer idea, file TopLevelTransferHandler.java
2008-10-16

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 Contribution forum : https://jdk-collaboration.dev.java.net/servlets/ProjectForumMessageView?forumID=1463&messageID=14135
2006-07-09

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