Lists Home |
Date Index |
From: "Wiedmann, Jochen" <firstname.lastname@example.org>
> What's always interesting for me is that people tend to treat
> the decision DOM, JDOM or SAX as an "all or nothing" question.
> In particular when dealing with large documents it makes quite
> some sense to mix both. For example:
Good point -- even if I do recall making it, and using this very
example, in a SAX2 book that should appear before long! :)
> - Write a SAX handler, that identifies an "interesting"
> part of the document.
> - If the SAX handler detects that part, it instantiates
> a DOM builder and fires further SAX events to the
> DOM builder.
Where unfortunately you've got to write your own DOM builder,
since most of the standard ones are set up to build entire
Document objects. Luckily that's a simple task.
> - If the SAX handler detects the end of the "interesting"
> part it supplies the created DOM object to some callback
> handler and terminates use of the DOM builder. After
> that it continues parsing.
> Writing such a SAX handler is much simpler than implementing
> the whole application in SAX. And the "interesting" DOM object
> will probably have no memory problems at all.
More, you can send such DOM objects through a pipeline
and discard them when you're done. That means you get
the benefits of a SAX-based pipelined processing mode
along with the "don't have to design a new data structure"
benefits of DOM, in one package.
Yes, mixing SAX with other APIs is a good way to get
all the benefits, without needing to learn "yet another API".