commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (JELLY-112) Create Script from SAX events
Date Fri, 27 Aug 2004 09:43:19 GMT
The following comment has been added to this issue:

     Author: Michael Lipp
    Created: Fri, 27 Aug 2004 2:42 AM
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.configure ();
  ... send SAX events to jellyParser
  Script script = jellyParser.getScript ();
  script.compile (); (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 "".
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:

View the issue:

Here is an overview of the issue:
        Key: JELLY-112
    Summary: Create Script from SAX events
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: jelly
             core / taglib.core

   Reporter: Michael Lipp

    Created: Fri, 25 Jun 2004 7:37 AM
    Updated: Fri, 27 Aug 2004 2:42 AM
Environment: All

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

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message