You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Scott Boag/CAM/Lotus <Sc...@lotus.com> on 2000/01/19 18:23:52 UTC

Fix for xalan-based xsl:include


Stefano, many many apologies for not getting this to you sooner (and before
your 1.6 release).  I've been stretched pretty thin over the last couple of
weeks for one reason or the other.

Stefano, I hope at some point you are planning to make a
stylesheet/transform object pool?  Depending on the transform, a lot of
time can be spent on the processing of the stylesheet.  Both Xalan and XT
allow you to create stylesheet objects that are independent of the content
being transformed.

Here is the patch I think you need to make to the XalanTransformer parser
liaison:

  class XMLParser extends XMLParserLiaisonDefault
  {
    Parser parser;
    Document document;

    public XMLParser(Parser parser)
    {
      this.parser = parser;
    }

    public Document createDocument()
    {
      return this.parser.createEmptyDocument();
    }

    public void parse(InputSource in) throws IOException, SAXException
    {
      this.document = this.parser.parse(in);

      // The Xalan stylesheet is normally built from SAX events,
      // so if a DocumentHandler is specified, we need to produce
      // SAX events from the DOM tree.
      if(null != m_docHandler)
      {
        org.apache.xalan.xpath.xml.TreeWalker tw
          = new org.apache.xalan.xpath.xml.TreeWalker(stylesheetProcessor);
        tw.traverse(this.document);

        // Note that when cocoon transitions to being more SAX based,
        // this function will be called recursivly while the parser is
        // still in the middle of a parse, and thus the parser will have
        // created on the fly (or perhaps cloned) since the Xerces parser
        // is not (to my knowledge) reentrant.
      }
    }

    public Document getDocument()
    {
      return this.document;
    }

    public boolean getShouldExpandEntityRefs()
    {
      return true;
    }

    public boolean supportsSAX()
    {
      return true;
    }
  }

-scott




Re: Fix for xalan-based xsl:include

Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
Yes. Very neat.

Dw.

Scott Boag/CAM/Lotus wrote:
> 
> Stefano, many many apologies for not getting this to you sooner (and before
> your 1.6 release).  I've been stretched pretty thin over the last couple of
> weeks for one reason or the other.
> 
> Stefano, I hope at some point you are planning to make a
> stylesheet/transform object pool?  Depending on the transform, a lot of
> time can be spent on the processing of the stylesheet.  Both Xalan and XT
> allow you to create stylesheet objects that are independent of the content
> being transformed.
> 
> Here is the patch I think you need to make to the XalanTransformer parser
> liaison:
> 
>   class XMLParser extends XMLParserLiaisonDefault
>   {
>     Parser parser;
>     Document document;
> 
>     public XMLParser(Parser parser)
>     {
>       this.parser = parser;
>     }
> 
>     public Document createDocument()
>     {
>       return this.parser.createEmptyDocument();
>     }
> 
>     public void parse(InputSource in) throws IOException, SAXException
>     {
>       this.document = this.parser.parse(in);
> 
>       // The Xalan stylesheet is normally built from SAX events,
>       // so if a DocumentHandler is specified, we need to produce
>       // SAX events from the DOM tree.
>       if(null != m_docHandler)
>       {
>         org.apache.xalan.xpath.xml.TreeWalker tw
>           = new org.apache.xalan.xpath.xml.TreeWalker(stylesheetProcessor);
>         tw.traverse(this.document);
> 
>         // Note that when cocoon transitions to being more SAX based,
>         // this function will be called recursivly while the parser is
>         // still in the middle of a parse, and thus the parser will have
>         // created on the fly (or perhaps cloned) since the Xerces parser
>         // is not (to my knowledge) reentrant.
>       }
>     }
> 
>     public Document getDocument()
>     {
>       return this.document;
>     }
> 
>     public boolean getShouldExpandEntityRefs()
>     {
>       return true;
>     }
> 
>     public boolean supportsSAX()
>     {
>       return true;
>     }
>   }
> 
> -scott

Re: Fix for xalan-based xsl:include

Posted by Stefano Mazzocchi <st...@apache.org>.
Scott Boag/CAM/Lotus wrote:
> 
> Stefano, many many apologies for not getting this to you sooner (and before
> your 1.6 release).  I've been stretched pretty thin over the last couple of
> weeks for one reason or the other.

Do not worry.
 
> Stefano, I hope at some point you are planning to make a
> stylesheet/transform object pool?  Depending on the transform, a lot of
> time can be spent on the processing of the stylesheet.  Both Xalan and XT
> allow you to create stylesheet objects that are independent of the content
> being transformed.

Uh, sure, why not? I'll put this in the todo list, but a hint code would
be appreciated.
 
> Here is the patch I think you need to make to the XalanTransformer parser
> liaison:
> 
>   class XMLParser extends XMLParserLiaisonDefault
>   {
>     Parser parser;
>     Document document;
> 
>     public XMLParser(Parser parser)
>     {
>       this.parser = parser;
>     }
> 
>     public Document createDocument()
>     {
>       return this.parser.createEmptyDocument();
>     }
> 
>     public void parse(InputSource in) throws IOException, SAXException
>     {
>       this.document = this.parser.parse(in);
> 
>       // The Xalan stylesheet is normally built from SAX events,
>       // so if a DocumentHandler is specified, we need to produce
>       // SAX events from the DOM tree.
>       if(null != m_docHandler)
>       {
>         org.apache.xalan.xpath.xml.TreeWalker tw
>           = new org.apache.xalan.xpath.xml.TreeWalker(stylesheetProcessor);
>         tw.traverse(this.document);

What is "stylesheetProcessor"?

>         // Note that when cocoon transitions to being more SAX based,
>         // this function will be called recursivly while the parser is
>         // still in the middle of a parse, and thus the parser will have
>         // created on the fly (or perhaps cloned) since the Xerces parser
>         // is not (to my knowledge) reentrant.
>       }
>     }
> 
>     public Document getDocument()
>     {
>       return this.document;
>     }
> 
>     public boolean getShouldExpandEntityRefs()
>     {
>       return true;
>     }
> 
>     public boolean supportsSAX()
>     {
>       return true;
>     }
>   }

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------