[
Lists Home |
Date Index |
Thread Index
]
Enzo Maggi wrote:
<snip/>
> For example, a program that do something usefull with XML, like counting
> the tags :->.
> My application writes XML programmatically with SWAN-output and I would
> like just to change / attach / derive a piece of code that computes the
> result.
> Now, In order to do this, I must have a complete new implementation of
> the class hierarchy. (Correct me if I am wrong)...
> The computation could be of course something interesting, like an
> XSLT-like transformation limited to the child:: and attribute:: axis.
>
> - If SWAN-output was an interface, let's say, a protocol, we could have
> bridges between SAX an SWAN. That is, a class that takes a SAX flow and
> produces the set of "SWAN" callbacks accordingly.
I don't think I'm following you on this. What's wrong with the SAX
interfaces for this purpose? It seems to me that an interface for swan
callbacks would just be a reinvention of the SAX interfaces. As it is,
you can always implement a SAX ContentHandler that filters SAX events,
augmenting or otherwise changing the events before passing them on to
another ContentHandler in the chain. Is there some reason why this
doesn't meet your need? The SAX interface is more unwieldy than the Swan
API, but I think any generic interface for the purpose of filtering XML
output is going to end looking pretty much like SAX.
Note that all output does actually get channeled through the top level
FragmentResult or DocumentResult (since it has the references to the SAX
Handlers), so you could theoretically create subclasses of these 2
classes and override the "output(Result)" method, I believe, to see what
is being output. The only problem with this is some of the classes are
not public, so they would be completely opaque. This is easy to change,
but I'm just not sure why the SAX interfaces are not sufficient for this
purpose.
One other possibility, if you are interested, is something else I'm
working on that sits as a layer on top of SAX and is designed for
handling input rather than output. Perhaps it would be a bit friendlier
than implementing a SAX ContentHandler, but it involves a bit more
overhead as you need a SAX adapter that maintains some contextual state
and translates events to the alternative interface. On the plus side,
though, you have access to more contextual state than SAX provides, and
you can dispense with those "startPrefixMapping" and "endPrefixMapping"
calls (they are handled automatically). I haven't released this yet, but
it will be released shortly and the code is there in my CVS repository
if you want to check it out.
The Javadoc for the relevant package is at:
http://swan.sourceforge.net/javadoc/core/net/sf/swan/xml/reader/package-summary.html
To use it you would instantiate a ContextHandler and use it as the SAX
ContentHandler. Provide an implementation of the InfosetProcessor
interface, and set is as the InfosetProcessor for the ContextHandler.
|
