Entities, Handlers and SAX - The DefaultHandler Class (Page 3 of 4 )
Because SAX is interface-driven, you have to do a lot of tedious work to get started with an XML-based application. For example, when you write your ContentHandlerimplementation, you have to implement each and every method of that interface,
Handlers Arenít Features
You need to carefully fix in your mind the difference between a feature, which affects what processing a parser does, and a handler, which simply allows your code to respond to certain events in that processing. As an example, realize that registering (or not registering) a ContentHandler doesnít affect whether processing instructions are parsed; even implementing (or not implementing) the processingInstruction() callback doesnít have an effect. The same is true of ErrorHandler ; whether you report errors or not, they still can occur.
Where this distinction becomes vital is in working with the DTDHandler ; implementing or registering an implementation of this handler has no effect on whether validation of your document occurs. DTDHandler doesnít do anything but provide notification of notation and unparsed entity declarations! Itís a feature that sets validation, not a handler instance:
Anything less than this (short of a parser validating by default) wonít get you validation.
even if you arenít inserting behavior into each callback. If you need an ErrorHandler , you add three more method implementations; using DTDHandler ? Thatís a few more. A lot of times, though, youíre writing lots of no-operation methods, as you only need to interact with a couple of key callbacks.
Fortunately, org.xml.sax.helpers.DefaultHandler can be a real boon in these situations. This class doesnít define any behavior of its own; however, it does implement ContentHandler , ErrorHandler , EntityResolver , and DTDHandler , and provides empty implementations of each method of each interface. So you can have a single class (call it, for example, MyHandlerClass ) that extends DefaultHandler . You then only override the callback methods youíre concerned with. You might implement startElement() , characters() , endElement() , and fatalError() , for example. In any combination of implemented methods, though, youíll save tons of lines of code for methods you donít need to provide action for, and make your code a lot clearer too. Then, the argument to setErrorHandler() , setContentHandler() ,and setDTDHandler() would be the same instance of this MyHandlerClass .
You can pass a DefaultHandler instance to setEntityResolver() as well, although (as Iíve already said) I discourage mixing EntityResolver implementations in with these other handlers.
SAX provides several extension interfaces. These are interfaces that SAX parsers are not required to support; youíll find these interfaces in org.xml.sax.ext. In some cases, youíll have to download these directly from the SAX web site (http://www.saxproject.org), although most parsers will include these in the parser download.
Because parsers arenít required to support these handlers, never write code that absolutely depends on them, unless youíre sure you wonít be changing parser. If you can provide enhanced features, but fallback to standard SAX, youíre in a much better position.