Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <340082653.1093599799891.JavaMail.apache@nagoya>
Date: Fri, 27 Aug 2004 02:43:19 -0700 (PDT)
From: commons-dev@jakarta.apache.org
To: commons-dev@jakarta.apache.org
Subject: [jira] Commented: (JELLY-112) Create Script from SAX events
In-Reply-To: <1749949342.1088174293126.JavaMail.apache@nagoya>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org