Lists Home |
Date Index |
- From: "Bill la Forge" <email@example.com>
- To: "Lars Marius Garshol" <firstname.lastname@example.org>, "XML Developers' List" <email@example.com>
- Date: Fri, 22 Jan 1999 10:16:57 -0500
I think weare very very close, particular when you consider that
DocumentHandler, DTDHandler, EntityResolver are the event receivers.
Now remember that, so far as event passing goes, MDSAX and ParserFilter
work the same. Its only in wiring them up that they are "particular". All we really
need is to loosen the wiring requirements. In both cases, this means little more than
providing a null constructor and subsequent set methods.
I do like your idea of having a seperate EventSource, which Parser and Filter both extend.
For when you have a tree of filters, it seems silly to call parse on one of the leaves, especially
if the leaf is particular to an element type.
On the other hand, I can see arguments for just using Parser. For
simple filter stacks, it makes things real easy and I like that.
So I really think the following is just great:
public interface Filter
implements Parser, DocumentHandler, DTDHandler, EntityResolver, ErrorHandler
public void setParser(Parser eventSource);
It means that in MDSAX we only need to change one interface and 4 classes. Changes to
ParserFilter can even be handled just by subclassing existing implementations, since John was
careful to use protected on the parser variable and will accept a null value in the constructor!
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)