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 ContentHandler implementation, 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:
reader.setFeature("http://xml.org/sax/features/validation", true);
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.
Extension Interfaces
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.
Next: LexicalHandler >>
More Java Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of the book Java and XML, Third Edition, written by Brett McLaughlin and Justin Edelson (O'Reilly, 2006; ISBN: 059610149X). Check it out today at your favorite bookstore. Buy this book now.
|
|
