abstract base helper class for XMLReader
Brought to you by:
dmegginson
Menu
▾
▴
#10 abstract base helper class for XMLReader
I seem to find myself writing the guts of an XMLReader
again and again - when writing an app that emits SAX2
events without first constructing an XML document (so
there is no parser involved) - e.g. from database
records, or from plain text being reformatted as XML,
etc.
I doubt I'm alone in this - see e.g. this SAX1
example: http://www.javaworld.com/javaworld/jw-01-
2000/jw-01-dbxml.html
I think it might be useful to provide the bare bones
of an XMLReader for those of us who do this kind of
thing, if there's no philosophical objection.
I'm attaching an example implementation which I'm
placing in the public domain, if you wish to use it.
Sample implementation of XMLReaderBase
Logged In: YES
user_id=14010
PS I should point out that the implementation of
getFeatureDefault() returns false for several features
which have unspecified defaults. This was because, for all
of the unspecified-default features with the exception
of 'is-standalone', a default of false allows the caller to
make safe assumptions. I think.
Logged In: YES
user_id=14010
Doh! Of course, all of those features/properties do not
have the correct prefix. I am not awake today...
Logged In: YES
user_id=44117
I marked this "low priority" for two reasons.
First, this is particularly easy to implement
for folk that need it, and it's not that widely
needed. It's just as simple to call the event
handlers directly (without wrapping them as shown
in that javaworld article).
Second, the particular implementation attached is
problematic. It's not appropriate as-is for a
"helpers" class, since it knows about extensions,
and it's overly enthusiastic about adding new APIs
for standard features and properties. (Since that
set is open-ended, following this pattern leads to
updating the class for every new feature/property...
not a good premise in terms of maintainence.)
However, if this code were to live in some non-SAX
package, it'd seem appropriate to include it (maybe
after some cleanup? :) as a nonstandard SAX tool.
Or, a much simplified version might be appropriate
as an "ext" class.
simplified base impl
Logged In: YES
user_id=14010
I agree with this being low priority. I feel I should
answer some of the other points.
- I don't deny this is easy to implement. Its just drudgery
to have to implement it each time you need it. The same
argument could be used against most abstract classes (since
they usually just provide some obvious simple
implementation).
- it is not always possible to call the event handlers
directly. In the TRAX API you need an XMLReader to start a
transformation.
- Support for extensions, features, properties... I accept
that this was all taken a bit far :).
I'm attaching a cleaned up version which knows nothing
about extensions, doesnt add any APIs, and only knows the
mandatory features. This is as minimal as you can get in
order to support the desired result - that you only need to
implement one 'parse' method to get a working XMLReader,
instead of trying to be a general-purpose base
implementation. Hopefully the changes make it a candidate
for the helpers package again.
Logged In: YES
user_id=14010
LOL...just looked at what I attached an I have the feature
names wrong again. Plus ca change. NS_FEATURE should of
course be http://xml.org/sax/features/namespaces.