[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Elliotte Rusty Harold" <elharo@metalab.unc.edu>
To: "Karl Waclawek" <karl@waclawek.net>
Cc: <xml-dev@lists.xml.org>; <sax-devel@lists.sourceforge.net>
Sent: Monday, March 08, 2004 9:22 AM
> >Yes, sounds more reasonable, as from the "cleanup" point of view such
> >a method is the counterpiece to parse() rather than startDocument().
> >Maybe we need both, one focussing on the actual end of the document,
> >one indicating the end of the parsing process. And then one can
> >divide responsibilities in a more intuitive way.
>
> The problem with this approach is that it's unwieldy, not impossible
> but not pretty. In this pattern, the data structures must be
> initialized in one class before calling parse, filled in in the
> ContentHandler during the parse, and then torn down or flushed after
> the parse in the first class.
It can all be done in the class that implements ContentHandler,
only the calls are coming from different places.
But it is more overhead, I agree. However, if we want to combine
initialization/finalization with the document boundary events, then
we run into the conceptual confusions this thread has demonstrated.
> Being able to rely on
> startDocument()/endDocument() in the ContentHandler allows all the
> initialization and tear-down code to easily go in the same class as
> the code that fills the data structure. It's all neatly unified.
Why could it not go in the same class in the other case?
> This
> doesn't necessarily do anything that the other pattern can't do. It's
> just cleaner and easier to follow by keeping all the related code in
> one place.
See above. Forcing endDocument() from a lexical point of view is wrong,
from a cleanup point of view is right (if it is the only event one can use).
Karl
|
