| Newsgroups |
gmane.text.xml.sax.devel |
| Message-ID |
<9B9D098EAC97D411938900805FFE1B6201E94ADC@gbvwfsmks00003> |
Thanks for the suggestions.
Let me give you a more concrete (but still hypothetical) example.
A WebEngine needs to be configured with a SAX source. It could
be a file, db, etc. So a property of the SAX source is where it
gets its SAX data from. I could configure both an InputSource and
an XMLReader but it does feel very messy. And it still leaves me
implementing XMLReader which is not Simple.
So I'm still needing a class that says "Get your SAX here", and
allows its users to decide when.
I guess the problem is not that I don't have a way to do it. I
think my ContentHandlerSource or any of Paul's solutions work.
The issue is just that this seams to me to be a common SAX problem
and SAX does not provide an answer.
I'm suggesting it should.
Joe.
Paul Brown wrote:
> > From: [email protected] [mailto:[email protected]]
> > public interface ContentHandlerSource
> > {
> > /**
> > * Call this method to get an XML document streamed
> > * passed ContentHandler
> > */
> > void writeToContentHandler(ContentHandler h) throws SAXEx...;
> > }
> > The logic behind it - sources of SAX events sometimes need to
> > be configured at run-time. Writing an XMLReader for each is time
> > consuming, and hard because InputSources aren't a good fit
> > to many data sources (in-memory, DBs, etc).
>
> Suggestions:
>
> 1) InputSource isn't final and XMLReader is an interface, so
> you can make your own versions that may be incompatible with
> other objects. For example, if you have an XMLReader
> implementation that turns a JDBC rowset into a stream of SAX
> events, then you are free to subclass InputSource to get a
> JDBCRowsetInputSource that has get/setStatement() and
> get/setConnection() methods, etc., and then have an XMLReader
> implementation that does:
>
> public void parse(InputSource is) throws SAXException {
> if (!(is instanceof JDBCRowsetInputSource)) {
> throw new SAXException(is.getClass().getName() + " is not "
> "a subclass of JDBCRowsetInputSource");
> }
> /* DO STUFF HERE */
> }
>
> This particular suggestion is intended to provide a
> reasonable level of compatibility with other SAX consumers.
> For instance, if you're using a TrAX-compliant XSLT
> processor, when it receives a SAXSource (XMLReader /
> InputSource pair), it does (or should do):
>
> ss.getXMLReader().parse(ss.getInputSource());
>
> to generate events. It's up to you to be sure that the
> InputSource subclass and XMLReader implementation are compatible.
>
> 2) You can create your own abstract class that has a
> pullFromSAX(XMLReader xr, InputSource is) method that
> attaches a ContentHandler, etc., and then calls parse on the
> supplied InputSource.
>
> 3) You can create a utility class with a static method that
> accepts a ContentHandler (and DeclHandler, etc., too?),
> XMLReader, and InputSource tuple and then performs the
> relevant operations. In this case, your
> writeToContentHandler() would be equivalent to
> UtilityClass.consume(this,myXR,myIS);
>
> Just some pre-coffee suggestions.
>
> -- Paul
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> List: sax-devel, [email protected]
> See: http://www.saxproject.org/
> https://lists.sourceforge.net/lists/listinfo/sax-devel
>
**********************************************************************************
The opinions expressed in this E-mail are those of the individual and
not necessarily the company. This E-mail and any files transmitted
with it are confidential and solely for the use of the intended recipients
**********************************************************************************
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
List: sax-devel, [email protected]
See: http://www.saxproject.org/
https://lists.sourceforge.net/lists/listinfo/sax-devel