On Tue, Sep 10, 2002 at 12:04:04PM -0400, Barrie Slaymaker wrote:
> On Mon, Sep 09, 2002 at 08:56:26PM -0500, Michael K. Neylon wrote:
> > [problems with hitting the ol' XSP twice in the same pipeline
> > Parts 1 and 2 work find. However, when I hit the second XSP
> > processing step, things go weird.
>
> As well it might; I think you have dueling dual XSP instances here.
>
> I think your two XSPs are colliding in their in-memory Perl code cache:
> the first one's probably compiling it's input page in to a Perl
> subroutine named partially after the path to the source page; the second
> is probably checking the cache and seeing that a properly named sub has
> already been compiled and rerunning it, thus regenerating the output
> from the first (XSP) stage instead of compiling the output from the 2nd
> (XSLT) stage, which is what this sounds like:
>
> > I've traced the output, and it
> > seems that instead of using the XML output from Part 2, it restarts
> > the XML from the original XSP file, thus making anything in the last 2
> > stages fail miserably.
>
> > Any idea of how to get this working? Is there a better way to set up
> > the pipeline?
>
> Get rid of stage 1 and, ideally, convert the LogicSheet in stage 2 to be
> a Perl taglib module.
>
> > I know that I could construct the SQL back at the first
> > XSP, but I'm trying to avoid repeating code...
>
> The encapsulation is a good idea, I recommend that you use a Perl
> taglib module instead of upstream XSLT + ESQL. This has several
> advantages (some of which may not apply to your situation, of course):
I took at look at the taglib implemenations, and it worried me a bit.
Unless I'm missing the blazingly obvious, it would seem that to do
this, I'd need a specialized taglib for each "page" that had a db
access point, which seems like more work that should be done.
So I've been looking around the docs some more, taking in ideas from
axkit sites and other places, and here's what I've got now:
- First, axkit delivers the passed CGI parameters as true parameters
to the xsl process, ie xsl:param's.
- There's no nice and simple way to iterate over all defined
xsl:param's.
- Even knowing what CGI params to look for, there's no 'standard' way
to get values from just names (eg, like perl interpolation will
understand ${$test}, but you can't do the same STANDARDLY in xslt.
HOWEVER, various xslt libraries, particular LibXSLT, offer extentions
like "saxon:evaluate" which can effectively do this.
So, what I've done is changed the xslt backengine to do ::LibXSLT
(also making sure XML::LibXSLT is up-to-date with the current version
of the libxslt.so).
Now, my first source doc (the .xsp page) can look something like:
<query name="list">
<table>
<params name="type"/>
</table>
<etc.../>
</query>
The first processing step in the pipeline now jumps to a
"insert_param.xsl" stylesheet, which contains the standard identity
transformations, in addition to this one:
<xsl:template match="params">
<xsl:variable name="paramname">
<xsl:value-of select="@name"/>
</xsl:variable>
<param>
<xsl:value-of
select="saxon:evaluate(concat('$', $paramname))"/>
</param>
</xsl:template>
which replaces the <params> in the original xml with the passed value
inside a <param> element. In essence, this all replaces the original
first XSP processing step where I simply used that for the Param taglib.
>From this point, I can proceed forward with the pipeline as from step
2, including leaving the XSP step 3 in there.
Obviously, I know I can improve the above transformation (such as
catching for missing parameters, possibly quoting them at this stage
as well), but this gives me a good start for what I want to do.
Just as a note, the "saxon:evaluate" function is not supported by
Sablotron (yet), thus requiring me to use LibXSLT which does support
it in later versions. Again, just make sure that if you install a new
LibXSLT to reinstall XML::LibXSLT as to compile against it (I was one
point getting different results from the command line as from AxKit).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
