Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX: Next Round
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!
Bill
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
