Cart
[Home] [By Thread] [By Date] [Recent Entries]
----- Original Message ----- From: "Elliotte Rusty Harold" <elharo@m...> To: "Karl Waclawek" <karl@w...> Cc: <xml-dev@l...>; <sax-devel@l...> 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
|
