The following comment has been added to this issue:
Author: Michael Lipp
Created: Fri, 27 Aug 2004 2:42 AM
Body:
Oh, I don't mind to subclass (though it is a bit silly to subclass only to change the
visibility of a single method). I am more concerned whether my solution is
"future-proof".
I could not derive my solution from the API description. I had to use the source (no
problem, that's what open source is for) and I have to use a protected method (those
tend to be less stable when version numbers increase) and I am using a sequence of
instructions that cannot be drived from the documentation.
JellyContext context = new JellyContext (jellyContext ());
// ExtXMLParser is XMLParser with changed visibility of configure
ExtXMLParser jellyParser = new ExtXMLParser ();
jellyParser.setContext(context);
jellyParser.configure ();
... send SAX events to jellyParser
Script script = jellyParser.getScript ();
script.compile ();
script.run (context, new XMLOutput(...));
Nothing in the documentation tells me that this sequence of invocations is correct. I
know from the source that I have to invoke configure after setContext. Actually I know
only from the source that I have to invoke configure at all!
Again, I don't mind subclassing. But if there is no directly documented support for
sending SAX events to a Jelly parser, I think a proper API documentation should state
what to do when subclassing. The constructor's documentation should include: "If you
subclass this class, be sure to invoke configure() after setting the context, but
before anything else." (This does not only tell me that I have to invoke configure,
much more important is that this implies that I do not have to do anything else!)
The API does not state, that you have to call "script.compile()" before you can use
"script.run()". I thought compilation was optional. OK, this was relatively easy to
find out. But I had to find out, while users of other types of XML source get direct
support. And lacking any documentation, how can I be sure that this is the way the API
is intended to be used and will support my solution in future versions as well?
I don't remember exactly which method it was (getScript?), but I remember that I had
to upgrade to a newer version of Jelly to be able to write the code above at all,
because one of the methods I needed was private in the Jelly version I started with.
Lucky me, that the Jelly version was changed "in time" for my project in this way. But
it shows that previously either nobody had thought about how to send SAX events to a
Jelly parser, or that I have chosen the wrong solution after all.
I think that Jelly should support receiving the XML as SAX events "out of the box" in
order to be efficiently used in a "streaming" environment as a filter. And I think it
should be documented how to do this. If you prefer adding something to the
documentation and having the user write a subclass, this is OK with me. I just think
it would be an advantage (and less effort than writing the documentation ;-)) if Jelly
provided a direct API-supported way of passing SAX events.
- Michael
---------------------------------------------------------------------
View this comment:
http://issues.apache.org/jira/browse/JELLY-112?page=comments#action_37852
---------------------------------------------------------------------
View the issue:
http://issues.apache.org/jira/browse/JELLY-112
Here is an overview of the issue:
---------------------------------------------------------------------
Key: JELLY-112
Summary: Create Script from SAX events
Type: Improvement
Status: Unassigned
Priority: Major
Project: jelly
Components:
core / taglib.core
Assignee:
Reporter: Michael Lipp
Created: Fri, 25 Jun 2004 7:37 AM
Updated: Fri, 27 Aug 2004 2:42 AM
Environment: All
Description:
Currently, there is no possibility to feed a SAX event stream through Jelly. There is
no ContentHandler for the Jelly script.
Currently we use a work-around: we define a class derived from XMLParser, for the sole
purpose of being able to invoke configure() :-(
Then we use this parser as ContentHandler and send all SAX events to it.
>From the parser we get the script (getScript()) and invoke compile() and run(...).
>While all this works, it is not really nice.
The funny thing is that XMLParser uses SAX events internally. I'd propose to make
getXMLParser() public and to automatically invoke compile() when the end document
event is received (removing the invocations from JellyContext).
- Michael
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
