Luke,
I'm happy to know that someone is trying to avoid XSP.
I dislike it for being too static, I'd rather prefer doing everything via
XSLT... as I'm currently struggling to do.
By the way, I think you may be interested in knowing that you can pass
request parameters within document() calls.
For instance, you can:
<xsl:variable name="v">vvvv</xsl:variable>
<xsl:variable name="w">wwww</xsl:variable>
<xsl:variable name="uri">
<xsl:value-of select="concat('cocoon:/b.xml', '?v=', $v, '&w=', $w)"/>
</xsl:variable>
<xsl:copy-of select="document($uri)"/>
...and b.xml will receive those two request parameters (v and w),
alleviating the matter of passing parameters from stylesheets to URIs.
Best regards,
---------------------------------------------
Luca Morandini
GIS Consultant
[EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
---------------------------------------------
> -----Original Message-----
> From: Luke Studley [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 06, 2001 1:00 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Inserting / Comining XML data
>
>
> Ah yes sorry - I missed the bottom part of the previous mail in
> my original
> reply.
>
> ... As Karl rightly points out this is pure XSLT/JAXP stuff, I don't use
> Xalan I use Saxon and it works just the same.
>
> Thinking about this more in terms of cocoon, maybe the best way
> of utilizing
> this sort of method is rather than to try and use it within logic
> sheets (if
> at all possible) to have a 2 layer transformer, e.g.
>
> <!-- Feed in your static XML -->
> <map:generate src="docs/{1}.xml"/>
> <!-- Transform in your dynamic XML fragments using the document() function
> -->
> <map:transform src="stylesheets/business_funcs.xsl"/>
> <!-- Final styling transformation of resultant XML to HTML etc. -->
> <map:transform src="stylesheets/simple-xml2html.xsl"/>
> <map:serialize/>
>
> So in effect you use this mechanism in place of XSP - although
> you are still
> able to use that as well as your original source!
>
> Do the newly registered protocols work within the sitemap as well? If they
> do you could get really silly and do sensibly:
> <map:transform src="http://stylerepository:9090/mystyle.xsl"/>
> or crazily
> <map:transform src="dynamic-styles://generate-4-customer/Larry.xsl"/>
> where you could dynamically generate (and cache) a stylesheet for
> a specific
> use which could compile in relevant rules and wotsits. A bit over
> the top -
> but could be used to effectively produce custom on the fly pre-compiled
> stylesheets.
>
> All the best
>
> Luke
>
>
>
> -----Original Message-----
> From: Karl Řie [mailto:[EMAIL PROTECTED]]
> Sent: 06 December 2001 11:18
> To: [EMAIL PROTECTED]
> Subject: RE: Inserting / Comining XML data
>
> points missed again, sorry! :-)
>
> 1: javax.xml.transform.Transformer has a setURIResolver(), so this is not
> adding stuff to xalan, this is using the javax.xml api.
>
> 2: it would NOT tie things down to xalan as ... again this is using the
> javax.xml api.
>
> 3: as i wrote in my email response to luke's orriginal request; the cocoon
> does not accept annything else than char/byte streams as source-handlers,
> javax.xml does. http is only a byte/char-stream and sometimes
> that might not
> be enough.
>
> mvh karl řie
>
>
>
> >I've been following this discussion. This is not rambling, the concept
> >works. I've done it before using http: That is, created a URIHandler or
> >something similar, but then wrapped it in a servlet and made
> sort of an XML
> >XPath requester that loads stuff from a database. However, I think Robs
> >point is that pretty most anything you'd want to do with a URIResolver
> >class, you could also do with http: (i.e. a servlet) So the
> calls might be
> >
> >http://localhost:8082/serve/catalog/cars/*
> >http://localhost:8082/serve/sales/invoices/0002332
> >
> >(I think you could probably even get the "http:localhost/serv" put
> somewhere
> >else so they would have to know that, but I'm not sure how...)
> >
> >The XSL processor would then go get it if you used "document()". And
> that's
> >a problem with the way you're viewing it I think. The "document()"
> function
> >is part of the XSL processing (Xalan), not part of cocoon as far as I can
> >tell. Now, you might be able to add stuff to Xalan, but then your XSL
> would
> >be tied to it.
> >
> >Unless you're talking about in the sitemap.xmap file. This get
> XSLTed down
> >to java, compiled, and run so presumedly it's handled a different way.
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
