Next Round

[david at megginson.com]

Bill la Forge writes:

 > I've always thought using the Parser interface for filters was a
 > bit heavy weight.  I wanted to keep filters very light so that the
 > cost of doing things like namespace and bunches of other things
 > would be no greater than having them done inside the parser, and
 > yet give you a lot more configurability.

If there's a common helper class that people can use as a base, then
filters can be very light anyway (the base class should just pass
through all events unmodified and provide access to registered
handlers).  Here's a filter that renames all "foo" elements to
"bar":

import org.xml.sax.AttributeList;
import org.xml.sax2.helpers.SAXFilter;

public class FooFilter extends SAXFilter
{

  public void startElement (String name, AttributeList atts)
  {
    if (name.equals("foo")) {
      getDocumentHandler().startElement("bar", atts);
    } else {
      getDocumentHandler().startElement(name, atts);
    }
  }

  public void endElement (String name)
  {
    if (name.equals("foo")) {
      getDocumentHandler().endElement("bar");
    } else {
      getDocumentHandler().endElement(name);
    }
  }
}

 > I also didn't think a lot of folks would be filtering DTD events,
 > that is unless they got extended.

If people are using DTD events at all, they'll probably want to filter 
them (fiddling with notations, etc.).  Likewise with lexical events.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)