cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: XSLT API Proposal (Draft 2)
Date Tue, 08 Feb 2000 23:20:36 GMT
Scott Boag/CAM/Lotus wrote:
> 
> Assaf Arkin <arkin@exoffice.com> wrote:
> > Actually, context is most often used not for one-per-thread, but for
> > one-per-activation.
> 
> Ah.  OK.  Then Context is out.

But I loved context, just as a form of passing parameters to a
transformation operation, not as a means of assuring
one-thread-per-call.

> No, I was thinking that the processor would remember that it had parsed it.
> On the other hand, it may not want to do a full parse... just a crufty
> search through the header.

Works fine with DOM, might be a bit slow with URLs (in particular
remote).

> 
> > How will it work with SAX?
> 
> Seriously, I don't know.  I'm not sure how getAssociatedStylesheet can be
> made to work with SAX, if it can at all.  Looking forward to ideas from
> other's.  This wasn't solved before either.

The question is, why and at what stage do you need the associated
stylesheet?

arkin


> > Or
> > is getAssociatedStylesheet a convenience method?
> 
> Not sure what you mean by that.
> 
> > How about TransformerResolver?
> 
> Maybe.
> 
> > How does that work with SAX?
> 
> See the chaining examples somewhere in this thread.  A work in progress...
> 
> -scott
> 
> 
>                     Assaf Arkin
>                     <arkin@exoffic        To:     Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
>                     e.com>                cc:     Kay Michael <Michael.Kay@icl.com>,
cocoon-dev@xml.apache.org,
>                     Sent by:              xalan-dev@xml.apache.org, James Clark <jjc@jclark.com>,
Steve Muench
>                     arkin@arkin.ex        <smuench@us.oracle.com>, Adam Winer <awiner@us.oracle.com>,
>                     office.com            Eduardo.Pelegrillopart@eng.sun.com
>                                           Subject:     Re: XSLT API Proposal (Draft 2)
> 
>                     02/08/00 04:31
>                     PM
> 
> 
> 
> > Frankly I like TransformContext a bit better than Transformation.  It
> gets
> > the idea across that this is a one-per-thread object, for the purpose of
> > non-static data during the transform.  I'm not sure if a Transformer is
> the
> > stylesheet, or if the Transformation is the stylesheet.
> 
> Actually, context is most often used not for one-per-thread, but for
> one-per-activation.
> 
> In Servlets and EJB the context belongs to an instance of the object. In
> JAAS you create one context per login operation. And so on.
> 
> One per thread is achieved only by specifying that a method is not
> reentrant either in the docs, by throwing an exception, etc.
> 
> You can always create one context and share it between threads.
> 
> > Processor or TransformFactory?  I kind of like TransformFactory better.
> > And then I was thinking...
> >
> > Maybe we could back out of having a SourceTree object, which introduces
> > certain problems, and just have:
> >
> > public interface TransformFactory
> > {
> > Transform createTransform(XSLTInputSource source);
> > XSLTInputSource getAssociatedStylesheet(XSLTInputSource source, String
> > media, String title, String charset);
> > // TransformSourceHandler just extends DocumentHandler with a
> getTransform
> > () method.
> > TransformSourceHandler getTransformSourceHandler(Parser parser, String
> > baseID);
> > }
> 
> Question, if I call getAssociatedStylesheet and then createTransform, do
> I need to parse the source document twice? How will it work with SAX? Or
> is getAssociatedStylesheet a convenience method?
> 
> How about TransformerResolver? Will be used to return a transformer
> given the stylesheet during processing, or return one given not
> stylesheet PI, so you can keep calling the same process() method but
> have some caching/default mechanism in the background.
> 
> > Transformer and Transformation just seem too close to me... I think
> people
> > would mix them up.  What do other's think?
> 
> Confusing.
> 
> > OK, let me try this as a close-to equivalent:
> >
> > TransformFactory tfactory = XSLTFactory.newTransformFactory(...);
> > XSLTInputSource transformSource = tfactory.getAssociatedStylesheet(
> > inputSource, null, null, null);
> > // I'm going to assume the processor should be able to handle an embedded
> > stylesheet
> > Transform transform = (null != transformSource) ?
> tfactory.createTransform(
> > transformSource)
> >           : tfactory.createTransform(new XSLTInputSource("default.xsl");
> > transform.process(transform.getContext(), sourceDoc, oprop);
> 
> How does that work with SAX?
> 
> arkin
> 
> >
> > -scott
> 
> --
> ----------------------------------------------------------------------
> Assaf Arkin                                           www.exoffice.com
> CTO, Exoffice Technologies, Inc.                        www.exolab.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org

Mime
View raw message