SAX: Next Round

[Rob Schoening]

>  > I think it would aid in the development of modular,
>  > re-usable handlers if you could register more than one with
>  > a parser.
>
> I disagree with this point -- I think that the filter approach goes
> much further towards general-purpose, reusable handlers; that said,
> there are other benefits to broadcasting events (such as doing two
> completely different things with the same input stream).

I agree with David.  The event/listener model is useful.  But unless it is
integral to the API, this kind of thing can be implemented easily outside
the API proper.

There are times when it is useful to have this kind of functionality
included in an API...particularly when you are using a factory and don't
have good control over the objects being instantiated.  But this doesn't
seem to be such a case.

I feel that the key issues here are function, not OO design.  Ultimately we
want the right code to get the right events with a minimum of effort.  Since
we're dealing *only* with events, it is possible to write adapters and
filters to end up with just about any interface imaginable.  The question is
(in my mind) how to do it so that 80% of uses need no custom adapters.

Rob


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)