On Mon, Sep 09, 2002 at 08:56:26PM -0500, Michael K. Neylon wrote: > I'm playing around with AxKit, XML, and all that, and finding it very > nice. > > However, in writing a personal test app, I've run into a problem. I'd > like to have a single XSP page that uses the ESQL to process the SQL > calls, as to avoid repeating the db/password/etc info all over the > place.
> Thus, upstream, I'd create an XML tree that has parts like: > > <query name="list"> > <table>somesuch</table> > <columns>somesuch</columns> > <where>value LIKE "somesuch"</where> > </query> > > This would then be processed by XSLT to make the right XML tree for the > XSP/ESQL commands, then return back to the original XSP page's > pipeline for further processing. > > This seems certainly reasonable, particular given the article at > http://www.perl.com/pub/a/2002/07/02/axkit.html > which describes a case of a XSLT upstream of an XSP page. Yup, should be doable. > So I've gone about making an XSP page with the following pipeline: > > <?xml-stylesheet href="NULL" type="application/x-xsp"?> > <?xml-stylesheet href="xsl/prep_query.xsl" type="text/xsl"?> > <?xml-stylesheet href="NULL" type="application/x-xsp"?> > <?xml-stylesheet href="xsl/parse_list.xsl" type="text/xsl"?> > <?xml-stylesheet href="xsl/page.xsl" type="text/xsl"?> > > 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): - You can share a single database connection between your taglibs and other parts of the site (authentication and authorization being the most frequent cases). - You can still have your custom ad hoc query tags (ie XMLified SQL like you show above) if you like - You can have common queries with custom tags instead of typing out the query in XML. This better isolates your queries from your processing pipeline, giving a higher level interface where you call queries usign custom tags - You can pre- and post-process query parameters and results more easily, for instance looking for illegal characters, invalid results, trimming overlong strings, etc. - You can test your canned queries using Perl's test suite and perhaps something like Test::Differences, so a broken query never makes it to the site. - You can share queries more easily between taglibs and other code > This is with AxKit 1.6-1 on a deb system with perl 5.8 behind it, under > Apache 1.3.26-1. "Normal" pipelines, with a single XSP at the > forefront, work just fine. :) - Barrie --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
