You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by "S. Woodside" <sb...@yahoo.com> on 2005/09/19 08:31:44 UTC

deja vu ... axkit: URIs don't support query parameters

Hi,

Before I get to that, Matt, you asked on Aug 5

> So what do I need *you* to do? I need you all to check out the  
> current CVS, and with XML::LibXSLT 1.58, make sure "make test" passes.

I've done this now on OS X 10.4.2. I'm running all the latest libxmls  
and libxslts and everything too. Make test passes and it works too...

Anyway, on to the query parameters thing.

Now that I have my favourite axkit: URIs back I just found with a  
nasty shock that they don't seem to pass through the query parameters.

I've set up what I think is a rather clever server side include  
system written in XSLT. I stick into my XML something like this:

<sax:include>
   <url>/weblog/weblog.xml</url>
   <query>display=front&amp;plurality=4</query>
</sax:include>

This will cause my XSLT to insert in that place whatever is the  
result of

<xsl:copy-of select="document('http://simonwoodside.com/weblog/ 
weblog.xml?isplay=front&amp;plurality=4')"/>

It's actually enormously useful and I use it all over my site now so  
that I can divide, say, the content for my home page, but insert & re- 
use "feeds" and such from other parts of the site (like the blog).

The *problem* is I have to harcode "simonwoodside.com" which means  
that when I'm on my development server as opposed to the production  
server it gets the wrong data...

So, is axkit: supposed to support query parameters / it would be nice!

--simon

--
http://simonwoodside.com



Re: deja vu ... axkit: URIs don't support query parameters

Posted by Matt Sergeant <ma...@sergeant.org>.
On 19 Sep 2005, at 02:31, S. Woodside wrote:

> So, is axkit: supposed to support query parameters / it would be nice!

It's kind of on the todo list. The thing is axkit: URIs run in the 
current request's process space, and so we need to find a way of 
temporarily replacing the request's idea of query params and bring them 
back after we're done.

It just needs a bit of JFDI I think :-)