Steve:
1) It should not be hard to add a function that will preserve the
resulting tree, and another that will accept it as stylesheet/input. If
that would suffice then it's OK.
2) It might be cool to be able to access these trees through a URI
scheme, much as with the 'arg:' scheme (for accessing documents in
memory). So you could call the processor say on 'tree:last-result'.
3) I thought about your idea of a 'persistent Processor object' and I
must say it does have several advantages. Thus a Processor would live
longer than just one stylesheet application, and would have its own pool
of ready-made trees, own processing options and registered handlers etc.
There would possibly be one processor per thread (NOTE that Sablotron
currently does not support multi-threading - would this work well with
your project?).
4) A nice thing about this is that it fits in my favourite idea of
debugging support (stepping through the stylesheet etc.)
5) Your hack: it's fine to see it's possible for someone to make his way
through the code. However I can't tell what happened in this particular
case without the patch. Would you please send it?
The trees are left as they are after the parse.
6) The objects: this is a bold concept, but the difficult part of it is
probably how to define the methods. I think we'll need some details to
decide how hard it would be to implement this. The variable references
present no problem as they already are being expanded where necessary
(e.g. in <xsl:element name="{$whats-the-name}"/>).
Regards,
Tom
Steve Willer wrote:
>
> On Mon, 15 May 2000, Kaiserovi wrote:
>
> > Well, we are aware of things that should be optimized in the code; with
> > some of them, it would not be difficult, and I expect a significant
> > improvement in performance when that is done. However, it takes some
> > time, and since Sablotron now runs at "reasonable" speed (at least for
> > us), I think it's better to try and fill in the missing functionality
> > first.
>
> Yes, although from my point of view I have to get a website up and
> running relatively soon (6 weeks), and I want to use a
> multiple-transformation architecture. Page building should be fairly fast.
>
> Architecturally, it would definitely be best if the "result" could
> optionally be a parse tree, which I can feed into the next process call as
> the XML input. I believe this is a relatively small API change (which I
> could perhaps make myself). Then there's the caching thing, and
> extensions...
>
> > You're right. The idea is that one Processor object corresponds to a
> > single run of a stylesheet on a document. On the other hand, the cache
> > would have to be persistent, kind of global within the shared library.
> > That's one possibility anyway.
>
> Yep. I started by making the Process object's datalist member a
> module-level static in proc.cpp. Then I killed the datalines.freeall()
> call. I tried running the same XML/XSL combination multiple times in one
> sabcmd call, but it found the cached result tree on the second try and got
> mad. So I changed makeTreeForURI() to call datalines.freerm() instead of
> exiting. It's a hack, I know, because maybe we would want to hold on to
> the result tree. But I wanted to try it.
>
> An interesting result: It was a lot faster for 100 loops (175ms per loop
> vs 520ms), but the output had only ctext and no tags. Is the XML or XSL
> tree being modified in-place during processing? If you want, I can send
> you a patch of what I've done so far, to play with it. I'm sure I'll
> continue to experiment, as I don't have a lot of time to come to a
> decision.
>
> > > My second question is about extension support. I need to figure out a way
> > > to get my system of XSL files somehow instantiating objects and making
> > > method calls for those objects. I don't want to do this with Cocoon-style
> > > full language embedding, but figured I could do it with a few extra tags
> > > in the XSL file, if there was support for expanding out XSL variable
> > > references within the tags. So my question, for those who know the
> > > architecture better than I, is: How hard would this be? Are there any
> > > plans for it? Could I hack it in easily?
> >
> > Ugh. I'm probably getting this wrong. What do you mean by "expanding out
> > XSL variable references within the tags", something like
> >
> > <my_tag_$name> expanded as, say, <my_tag_JOE> ?
>
> No. XSLT already has a variable capability; I wanted to extend that.
> Here's a not-well-planned example:
>
> <xsl:template match="/">
> <xsl:variable name="website">
> <xsl:object name="Website" website_id="{input/website_id}"/>
> </xsl:variable>
> <xsl:dumpmethod variable="website" method="search_products"
> text="{input/formdat/text}"/>
> </xsl:template>
>
> This example code would instantiate a Website object, giving its
> constructor a website_id parameter, and putting the result into the XSL
> variable "website". Then it would call
> website->search_products({input/formdat/text}) and dump the resulting
> hashtree or whatever into an XML tree. I would also want to be able to do
> something like:
>
> <xsl:dumpmethod variable="product" method="set_website"
> website_id="{$website}">
>
> See, all of this would involve expanding any variable or tag references
> inside the tag, then passing it on to some extension callback function,
> and then working with the results in whatever way it needs to (like
> putting the results into another variable). I realize my scheme isn't
> well-formed, cuz you can't make a DTD for it; I haven't thought it all
> through in an XML way yet.
