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]>
