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.
