Author: Bryan Boone

Everyday I read Java newsgroups that have programmers requesting validation for the JTextComponents. All of the suggestions, even from JavaSoft tend to be toward extending PlainDocument and performing the validation in the an overriden

public void insertString(int offset, String str, AttributeSet a){}

function found in the Document interface.

That is:

public class MyDocument extends PlainDocument {
    void insertString(int offset, String str, AttributeSet a){
        if(validText(str)) //some validation routine
            super.insertString(offset, str, a);
        else
            java.awt.Toolkit.getDefaultToolkit().beep();
    }
}

I took a different approach, assuming that at anytime JavaSoft could switch the contract out from under me and have the default Document for JTextComponents to change from PlainDocument to something else. I took the containment approach to text validation.

The first step was to create a wrapper, VetoableTextAdapter, whose constructor takes a JTextComponent. I figured that was "safe enough". The contract of VetoableTextAdapter class provides methods to:

    public final JTextComponent getJTextComponent() {...}
    public final Document getDocument() {...}
    public final void setDocument(Document document) {...}
    public void addVetoableChangeListener(VetoableChangeListener l){...}
    public void removeVetoableChangeListener(VetoableChangeListener l){...}

getJTextComponent() just returns the JTextComponent that was used for the creation of the class.

getDocument() returns the Document that is currently associated with the JTextComponent

setDocument(Document document) allows you to change Document that is currently associated with the JTextComponent.

This is just a convenience feature, since the VetoableTextAdapter
listens for the JTextComponent to change his Document and reattaches appropriately.

The "magic" of the VetoableTextAdapter lies in the

addVetoableChangeListener(VetoableChangeListener l)

and

removeVetoableChangeListener(VetoableChangeListener l)

Internally, the VetoableTextAdapter creates a DocumentChangeListener and
adds it to the Document of the JTextComponent. When DocumentEvents occur, the VetoableTextAdapter creates and fires a PropertyChangeEvent.
If the PropertyChangeEvent is "vetoed" then the VetoableTextAdapter uses the UndoManager to undo the last edit. This is trickey, since JavaSoft doesn't allow you to change a Document as a response to a DocumentEvent
so the SwingUtilities.invokeLater(..) is used.

What this means is that all text validators can be reduced to VetoableChangeListeners (hurray).

Additionally, I've extended VetoableTextAdapter to TextChangeEventAdapter which emits TextEvents when there are changes in the Document of the JTextComponent.

Furthermore, for convenience, I've written an abstract InputTextLimiter
which can be easily extended for validation purposes. However, all that needs to occur is that a text validator implement the VetoableChangeListener interface.

Please feel free to contact me at Bryan.Boonea@sas.com
Let me know if you find bugs or find this code useful.

Download source files

Posted On: 30-Apr-1999

internet.commerce