RE: Inserting / Comining XML data
True enough. Concede the point. But my original stylesheets and logic ran in a standalone application and didn't need to call a servlet via http. Also you might struggle to access local beans, files etc using http unless your servlet container is running in process. I guess we agree that this is possible - whether through your http/servlet requests or my own fantastical made up uris - but the question I am interested in is whether you think this is a good way of structuring things, i.e. style your page (or result fragment) and pull in the pieces you need as opposed to the more traditional cocoon way of assemble all the things you need and then style it I've only been using C2 for a few days - but this is the biggest hurdle I've had to overcome in porting my original stylesheets. Just trying to figure out if there is a more Cocoon Way for doing what I'm trying to do or whether I spend the effort to delve into C2 and get my method working within cocoon. Thanks for response though. Luke -Original Message- From: Kirk Woerner [mailto:[EMAIL PROTECTED]] Sent: 06 December 2001 02:22 To: [EMAIL PROTECTED] Subject: RE: Inserting / Comining XML data Hey, 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]
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]
RE: Inserting / Comining XML data
OK. This stuff is over my head :-( , but at the risk of being (more) annoying why couldn't you return this with http? Is the performance that much better? Is it a better architectural design? best, -Rob yes performance is much better, consider that cocoon2 is totally sax driven, so giving cocoon2 a http feed will lead to a parsing process. even with validation off this represent a huge overhead! mvh karl øie - 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]
RE: Inserting / Comining XML data
1. Can you use the new url protocol from all stylesheets, i.e. Transformers and logicsheets? no this only apply for the default xslt transformer :-(, you will have to hack each and every one if you need javax.xml.Source support, but if you only requires org.xml.sax.InputSource support you should get it to work in all transformers by creating the Source Handler.. (i hope) 2. When you want to cache your data (in particular in the session object) how do you achieve this? I can see that in org.apache.cocoon.environment.Source you may have access to the request environment (via the factory), but with org.apache.cocoon.components.xslt.XSLTProcessorImpl you don't have access to any such thing (although I suppose you could create your own static storage somehow and check for sessions being invalidated to clear out data.) I will let you know how I get on anyway. the XSLTProcessorImpl is Composable so will have access to the ComponentManager object at compose(), this will allow you to perform a lookup on all cocoon roles, also the servletsession like (ps: the session will perhaps not be valid at accesstime, try it out...): req = (HttpServletRequest)manager.lookup(HttpEnvironment.HTTP_SERVLET_CONTEXT); ses = req.getSession(); if you take a look at the XSLTProcessorImpl.java http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/org/apache/cocoon/componen ts/xslt/XSLTProcessorImpl.java?rev=1.13content-type=text/vnd.viewcvs-markup ) you will find it has it's own store implementation, but here is a problem because the transformers are not cacheable (i think) like the generators. you will have to produce your own caching system, but that one chould preferably be at the other side of the protocol... (ie transparent for cocoon) mvh karl øie - 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]
RE: Inserting / Comining XML data
the XSLTProcessorImpl is Composable so will have access to the ComponentManager object at compose(), this will allow you to perform a lookup on all cocoon roles, also the servletsession like (ps: the session will perhaps not be valid at accesstime, try it out...): req = (HttpServletRequest)manager.lookup(HttpEnvironment.HTTP_SERVLET_CONTEXT); ses = req.getSession(); erm... this is ofcourse a big lie! HttpEnvironment.HTTP_SERVLET_CONTEXT is not necessarily in the component manager's register by default... someone has to put it there :-) mvh karl øie - 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]
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]
RE: Inserting / Comining XML data
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/xsl:variable
xsl:variable name=w/xsl:variable
xsl:variable name=uri
xsl:value-of select=concat('cocoon:/b.xml', '?v=', $v, 'amp;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
RE: Inserting / Comining XML data
Diana, regarding performance issues... I don't know much about it :( Regarding the sentence Now that Cocoon2 has a SAX-driven pipeline..., I beg to differ, since the pipeline is NOT SAX-driven. Yes, the sitemap is static, I mean, you cannot decide midway in a pipeline to choose a different path (say, a different stylesheet) based on SAX events. Anyhow, the creative use of document() could make a lot of things possible... I'll investigate this further. Best regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: terracare [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 2:48 PM To: [EMAIL PROTECTED] Subject: Re: Inserting / Comining XML data 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. This was my original approach with Cocoon1 -- trying to use XSLT for everything -- but I read a number of posts that claimed better performance with XSP so I minimized my use of XSLT for all but presentation purposes. Now that Cocoon2 has a SAX-driven pipeline, and if we write efficient XSLT, is it correct to assume, generally, that the performance issue with XSLT is less of an issue now? Diana - 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]
RE: Inserting / Comining XML data
the first step would be to tweak the XSLTProcessor interface to also accept a setURIResolver() from the sitemap. This is the only thing my hack does (but not from the sitemap, i override it manually). But if you could define a custom URIResolver(s) from the cocoon.xconf or sitemap.xmap and the transfromer(s) would hounour the entries it would make it easier to create custom resolvers without hacking the XSLTProcessorImpl(s). mvh karl oie -Original Message- From: Luca Morandini [mailto:[EMAIL PROTECTED]] Sent: 6. desember 2001 15:07 To: [EMAIL PROTECTED] Subject: RE: Inserting / Comining XML data Diana, regarding performance issues... I don't know much about it :( Regarding the sentence Now that Cocoon2 has a SAX-driven pipeline..., I beg to differ, since the pipeline is NOT SAX-driven. Yes, the sitemap is static, I mean, you cannot decide midway in a pipeline to choose a different path (say, a different stylesheet) based on SAX events. Anyhow, the creative use of document() could make a lot of things possible... I'll investigate this further. Best regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: terracare [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 2:48 PM To: [EMAIL PROTECTED] Subject: Re: Inserting / Comining XML data 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. This was my original approach with Cocoon1 -- trying to use XSLT for everything -- but I read a number of posts that claimed better performance with XSP so I minimized my use of XSLT for all but presentation purposes. Now that Cocoon2 has a SAX-driven pipeline, and if we write efficient XSLT, is it correct to assume, generally, that the performance issue with XSLT is less of an issue now? Diana - 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]
Re: Inserting / Comining XML data
Luca, Regarding the sentence Now that Cocoon2 has a SAX-driven pipeline..., I beg to differ, since the pipeline is NOT SAX-driven. I just based my impression on most recent Cocoon2 announcement (from which I quote): Designed for performance and scalability around pipelined SAX processing, Cocoon offers a flexible environment based on the separation of concerns between content, logic and style. How is that different from what I said? I'm not at all disagreeing with the potential of pullMVC using the document() function, I'm just trying to figure out best practices... Diana - 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]
RE: Inserting / Comining XML data
Luke,
yes, there is a picture emerging... though I'm so ignorant about the Cocoon
inside workings that I cannot tell you how far we can go.
Well, my wish for the new year is... a dynamic sitemap.
It would be like a sort of master stylesheet, whose input is the invoked URI
and related parameters (request parameters, session parameters,... etc) and
the process is wholly driven by SAX-events.
Is it too much to wish for ?
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 3:12 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Inserting / Comining XML data
Another useful tidbit - XSLT parameter passing into documents - never
thought of that.
I like it. I think there enough of a picture emerging here that I will
proceed down this route rather than XSP and see how far I can get.
I see in your examaple that you use document() with a cocoon: url
as a kind
of replacement for the aggregate action. Also a neat trick.
Thanks
Luke
-Original Message-
From: Luca Morandini [mailto:[EMAIL PROTECTED]]
Sent: 06 December 2001 13:25
To: [EMAIL PROTECTED]
Subject: RE: Inserting / Comining XML data
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/xsl:variable
xsl:variable name=w/xsl:variable
xsl:variable name=uri
xsl:value-of select=concat('cocoon:/b.xml', '?v=', $v, 'amp;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
-
-
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]
RE: Inserting / Comining XML data
Diana, well, the point is that the pipeline drives the sequence of transformation stages (XML-XSL-HTML, for instance), but it is not driven by it. For instance, you cannot use a particular SAX event, say, the presence of element login-failure message=Wrong password/ to redirect the pipeline to a different URI. Some weeks ago I had an interesting e-mail exchange with Giacomo Pati on this... if you like, you could read those messages in the mailing list archives. Best regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: terracare [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 06, 2001 3:13 PM To: [EMAIL PROTECTED] Subject: Re: Inserting / Comining XML data Luca, Regarding the sentence Now that Cocoon2 has a SAX-driven pipeline..., I beg to differ, since the pipeline is NOT SAX-driven. I just based my impression on most recent Cocoon2 announcement (from which I quote): Designed for performance and scalability around pipelined SAX processing, Cocoon offers a flexible environment based on the separation of concerns between content, logic and style. How is that different from what I said? I'm not at all disagreeing with the potential of pullMVC using the document() function, I'm just trying to figure out best practices... Diana - 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]
Re: Inserting / Comining XML data
- Original Message - From: terracare [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 06, 2001 2:48 PM Subject: Re: Inserting / Comining XML data 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. This was my original approach with Cocoon1 -- trying to use XSLT for everything -- but I read a number of posts that claimed better performance with XSP so I minimized my use of XSLT for all but presentation purposes. Now that Cocoon2 has a SAX-driven pipeline, and if we write efficient XSLT, is it correct to assume, generally, that the performance issue with XSLT is less of an issue now? It's faster than before, but to get max efficiency you must use the best tool for the job. XSPs are good at content generation, all the rest should be done via other components. Sometimes you can easilly generate stuff without having all in memory and using SAX to its fullest, and making XSLT do some of these things makes it impossible to have these benefits. Nicola Ken Barozzi These are the days of miracle and wonder... ...so don't cry baby, don't cry [EMAIL PROTECTED] Paul Simon - 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]
RE: Inserting / Comining XML data
Whoosh - point missed! ;-)
That's precisely what I wanted to do - to pull dynamic XML data into the XSL
layer using the document() function. To do this though you need access to
the underlying URIResolver for the stylesheet - which Karl has kindly
provided a solution for.
Just another way to skin a cat :-)
Luke
-Original Message-
From: Robert Koberg [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2001 18:09
To: [EMAIL PROTECTED]
Subject: Re: Inserting / Comining XML data
I am just coming into this thread, but couldn't you use the XSLT document
function to bring in other XML (unless I am missing the point?)?
best,
-Rob
- Original Message -
From: Luke Studley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 05, 2001 7:38 AM
Subject: RE: Inserting / Comining XML data
Thanks Karl.
Glad to know somebody has had similar thoughts/needs.
I will try this. You're right this doesn't replace generators - but it
does
allow you to quite easily implement some sort of Pull MVC model a
opposed
to the generator push model - and will allow me to use my existing
stylesheets mostly unchanged.
Cheers
Luke
-Original Message-
From: Karl Øie [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2001 12:49
To: [EMAIL PROTECTED]
Subject: RE: Inserting / Comining XML data
3. Maybe I could use some sort of custom URL protocol manager like the
cocoon:/ and resource:/? Is it possible to supply new instances of
these?
4. Or I could use my URI resolvers again? Is it possible to set Custom
URI
solvers in C2
i have found two ways to accomplish this, but it took some time to find
out,
mostly because this is not very well documented yet... ok here we go:
in the cocoon.xconf file there is a source-handler entry, you can
create
own protocols here:
source-handler
protocol name=cool
class=org.apache.cocoon.components.source.CoolSourceFactory/
/source-handler
then you will have to create two classes called
org.apache.cocoon.components.source.CoolSourceFactory and
org.apache.cocoon.components.source.CoolSource. they will have to
implement org.apache.cocoon.components.source.SourceFactory and
org.apache.cocoon.environment.Source. Where the CoolSourceFactory
resolves urls with cool:/some/thing.xml and creates a CoolSource for it.
now you can refere to cool:/some/thing.xml many places in your project.
BUT this didn't work for me because the
org.apache.cocoon.environment.Source interface expects a
org.xml.sax.InputSource and it delivers a characterstream or bytestream
back, and i had a sax/dom source and i didn't want to serialize it to text
to get it parsed again... so i snooped around some more and found this:
again in your cocoon.xconf there is an entry for your default
transformer.
i hacked mine like this:
xslt-processor
class=org.apache.cocoon.components.xslt.KarlsXSLTProcessorImpl
logger=root.xslt
parameter name=use-store value=true/
parameter name=incremental-processing value=false/
/xslt-processor
then i created a class called
org.apache.cocoon.components.xslt.KarlsXSLTProcessorImpl containing this
(please not that i had to create it in the
org.apache.cocoon.components.xslt
package to be allowed to extend XSLTProcessorImpl) :
public class XonataXSLTProcessorImpl extends XSLTProcessorImpl {
public javax.xml.transform.Source resolve(String href, String base)
throws
TransformerException {
if (!href.startsWith(karl:)) {
return super.resolve(href,base);
}
else {
SAXSource source = new SAXSource( ... );
or
DOMSource source = new DOMSource( ... );
or
StreamSource source = new StreamSource( ... );
return source;
}
}
}
this way i can respond and create any SAX/DOM/Stream source for any
protocol
for the transformer, and i can use
document('rmi://myserver/mydatachunk')
in my xsl documents. this does not replace a generator thou
i would be happy if anyone could tell me if there is an easier way to
create
protocol handlers that can deliver SAX or DOM and not only Stream.
mvh karl øie
-
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
RE: Inserting / Comining XML data
to place the point precisely:
you can use document(), but it only accepts two kinds of urls, file: and
cocoon:, this hack enables you to get content from say, a database or
something...
mvh karl øie
-Original Message-
From: Luke Studley [mailto:[EMAIL PROTECTED]]
Sent: 5. desember 2001 17:12
To: '[EMAIL PROTECTED]'
Subject: RE: Inserting / Comining XML data
Whoosh - point missed! ;-)
That's precisely what I wanted to do - to pull dynamic XML data into the XSL
layer using the document() function. To do this though you need access to
the underlying URIResolver for the stylesheet - which Karl has kindly
provided a solution for.
Just another way to skin a cat :-)
Luke
-Original Message-
From: Robert Koberg [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2001 18:09
To: [EMAIL PROTECTED]
Subject: Re: Inserting / Comining XML data
I am just coming into this thread, but couldn't you use the XSLT document
function to bring in other XML (unless I am missing the point?)?
best,
-Rob
- Original Message -
From: Luke Studley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 05, 2001 7:38 AM
Subject: RE: Inserting / Comining XML data
Thanks Karl.
Glad to know somebody has had similar thoughts/needs.
I will try this. You're right this doesn't replace generators - but it
does
allow you to quite easily implement some sort of Pull MVC model a
opposed
to the generator push model - and will allow me to use my existing
stylesheets mostly unchanged.
Cheers
Luke
-Original Message-
From: Karl Øie [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2001 12:49
To: [EMAIL PROTECTED]
Subject: RE: Inserting / Comining XML data
3. Maybe I could use some sort of custom URL protocol manager like the
cocoon:/ and resource:/? Is it possible to supply new instances of
these?
4. Or I could use my URI resolvers again? Is it possible to set Custom
URI
solvers in C2
i have found two ways to accomplish this, but it took some time to find
out,
mostly because this is not very well documented yet... ok here we go:
in the cocoon.xconf file there is a source-handler entry, you can
create
own protocols here:
source-handler
protocol name=cool
class=org.apache.cocoon.components.source.CoolSourceFactory/
/source-handler
then you will have to create two classes called
org.apache.cocoon.components.source.CoolSourceFactory and
org.apache.cocoon.components.source.CoolSource. they will have to
implement org.apache.cocoon.components.source.SourceFactory and
org.apache.cocoon.environment.Source. Where the CoolSourceFactory
resolves urls with cool:/some/thing.xml and creates a CoolSource for it.
now you can refere to cool:/some/thing.xml many places in your project.
BUT this didn't work for me because the
org.apache.cocoon.environment.Source interface expects a
org.xml.sax.InputSource and it delivers a characterstream or bytestream
back, and i had a sax/dom source and i didn't want to serialize it to text
to get it parsed again... so i snooped around some more and found this:
again in your cocoon.xconf there is an entry for your default
transformer.
i hacked mine like this:
xslt-processor
class=org.apache.cocoon.components.xslt.KarlsXSLTProcessorImpl
logger=root.xslt
parameter name=use-store value=true/
parameter name=incremental-processing value=false/
/xslt-processor
then i created a class called
org.apache.cocoon.components.xslt.KarlsXSLTProcessorImpl containing this
(please not that i had to create it in the
org.apache.cocoon.components.xslt
package to be allowed to extend XSLTProcessorImpl) :
public class XonataXSLTProcessorImpl extends XSLTProcessorImpl {
public javax.xml.transform.Source resolve(String href, String base)
throws
TransformerException {
if (!href.startsWith(karl:)) {
return super.resolve(href,base);
}
else {
SAXSource source = new SAXSource( ... );
or
DOMSource source = new DOMSource( ... );
or
StreamSource source = new StreamSource( ... );
return source;
}
}
}
this way i can respond and create any SAX/DOM/Stream source for any
protocol
for the transformer, and i can use
document('rmi://myserver/mydatachunk')
in my xsl documents. this does not replace a generator thou
i would be happy if anyone could tell me if there is an easier way to
create
protocol handlers that can deliver SAX or DOM and not only Stream.
mvh karl øie
-
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
Re: Inserting / Comining XML data
are you saying something like this does not work?
xsl:value-of select=document('http://tiller:8080/koberg/boo.xml')/boo/
or
xsl:value-of select=document('http://tiller:8080/MyServlet')/boo/
With the xml being:
booboo/boo
It works in my processor (saxon, I remember it working in xalan too??). I
thought any uri will work just as long as it returns xml??
best,
-Rob
- Original Message -
From: Karl Øie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 05, 2001 8:17 AM
Subject: RE: Inserting / Comining XML data
to place the point precisely:
you can use document(), but it only accepts two kinds of urls, file: and
cocoon:, this hack enables you to get content from say, a database or
something...
mvh karl øie
-Original Message-
From: Luke Studley [mailto:[EMAIL PROTECTED]]
Sent: 5. desember 2001 17:12
To: '[EMAIL PROTECTED]'
Subject: RE: Inserting / Comining XML data
Whoosh - point missed! ;-)
That's precisely what I wanted to do - to pull dynamic XML data into the
XSL
layer using the document() function. To do this though you need access to
the underlying URIResolver for the stylesheet - which Karl has kindly
provided a solution for.
Just another way to skin a cat :-)
Luke
-Original Message-
From: Robert Koberg [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2001 18:09
To: [EMAIL PROTECTED]
Subject: Re: Inserting / Comining XML data
I am just coming into this thread, but couldn't you use the XSLT document
function to bring in other XML (unless I am missing the point?)?
best,
-Rob
- Original Message -
From: Luke Studley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, December 05, 2001 7:38 AM
Subject: RE: Inserting / Comining XML data
Thanks Karl.
Glad to know somebody has had similar thoughts/needs.
I will try this. You're right this doesn't replace generators - but it
does
allow you to quite easily implement some sort of Pull MVC model a
opposed
to the generator push model - and will allow me to use my existing
stylesheets mostly unchanged.
Cheers
Luke
-Original Message-
From: Karl Øie [mailto:[EMAIL PROTECTED]]
Sent: 05 December 2001 12:49
To: [EMAIL PROTECTED]
Subject: RE: Inserting / Comining XML data
3. Maybe I could use some sort of custom URL protocol manager like the
cocoon:/ and resource:/? Is it possible to supply new instances of
these?
4. Or I could use my URI resolvers again? Is it possible to set Custom
URI
solvers in C2
i have found two ways to accomplish this, but it took some time to find
out,
mostly because this is not very well documented yet... ok here we go:
in the cocoon.xconf file there is a source-handler entry, you can
create
own protocols here:
source-handler
protocol name=cool
class=org.apache.cocoon.components.source.CoolSourceFactory/
/source-handler
then you will have to create two classes called
org.apache.cocoon.components.source.CoolSourceFactory and
org.apache.cocoon.components.source.CoolSource. they will have to
implement org.apache.cocoon.components.source.SourceFactory and
org.apache.cocoon.environment.Source. Where the CoolSourceFactory
resolves urls with cool:/some/thing.xml and creates a CoolSource for
it.
now you can refere to cool:/some/thing.xml many places in your
project.
BUT this didn't work for me because the
org.apache.cocoon.environment.Source interface expects a
org.xml.sax.InputSource and it delivers a characterstream or bytestream
back, and i had a sax/dom source and i didn't want to serialize it to
text
to get it parsed again... so i snooped around some more and found this:
again in your cocoon.xconf there is an entry for your default
transformer.
i hacked mine like this:
xslt-processor
class=org.apache.cocoon.components.xslt.KarlsXSLTProcessorImpl
logger=root.xslt
parameter name=use-store value=true/
parameter name=incremental-processing value=false/
/xslt-processor
then i created a class called
org.apache.cocoon.components.xslt.KarlsXSLTProcessorImpl containing
this
(please not that i had to create it in the
org.apache.cocoon.components.xslt
package to be allowed to extend XSLTProcessorImpl) :
public class XonataXSLTProcessorImpl extends XSLTProcessorImpl {
public javax.xml.transform.Source resolve(String href, String base)
throws
TransformerException {
if (!href.startsWith(karl:)) {
return super.resolve(href,base);
}
else {
SAXSource source = new SAXSource( ... );
or
DOMSource source = new DOMSource( ... );
or
StreamSource source = new StreamSource( ... );
return source;
}
}
}
this way i can respond and create any SAX/DOM/Stream source for any
protocol
for the transformer, and i can use
document('rmi://myserver/mydatachunk')
in my xsl documents. this does not replace a generator thou
i would be happy if anyone could tell me
RE: Inserting / Comining XML data
Subject: RE: Inserting / Comining XML data Sorry Rob, I'm not explaining it well, but I'll persevere because I'd like to see where it goes myself and maybe get other peoples options on whether it is a valid way of doing things or not. [ deleted ] So from a Pull MVC point of view you could give your screen designers / stylesheet programmers a protocol document space (PDS) as their interface to the back end which they use at will without ever having to come back to the model layer to ensure the data is passed in (push), e.g. your PDS might look like: catalog://cars/* catalog://vans/* sales://invoices/0002332 orders://customer/Larry?from=20001512 Each type returns a doc of a predefined DTD so you have a totally clean interface between web designers and backend logic - no custom tags, extension elements, logic sheets - just a set of URLs and DTDs. Sort of thing. Sorry for the rambling and rampant acronym coining. It's late and I'm beginning to think this is a much better idea than I previously thought - oh no! not another redesign ;-) Hey, 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]
Inserting / Comining XML data
Hiya - Newbie question again,
I'm looking for some advice on the best way to include some dynamically
generated XML data in C2.
I'm new to this, but can see there are a plethora of ways, but I can't yet
see the best way for me.
In my original system I used XSL stylesheets and Custom URIResolvers to
'pull' data in to a stylesheet using the document() function - e.g.
document('rmi://myserver/mydatachunk') sort of thing.
How is this sort of thing accomplished with C2?
1. Using XSP seems to be a good way to insert some small strings - but I
couldn't see any examples (or if it is possible) to insert whole XML
documents in situ in the target doc. And besides to choose which data to
insert at this level seems to break the MVC paradigm - as I need to know
about the view I am catering for.
2. Aggregating - this again seems like a push method whereby you have to
have the data already in memory or on disk somewhere in order to combine it.
3. Maybe I could use some sort of custom URL protocol manager like the
cocoon:/ and resource:/? Is it possible to supply new instances of these?
4. Or I could use my URI resolvers again? Is it possible to set Custom URI
resolvers in C2
5. I haven't had much to do with actions yet? Could they be used to load the
XML data chunk and stick it in some sort of context that could then be fed
into the Transformer layer.
Please tell me what you think / flame me etc. as I'm all in a muddle.
Yours, slightly frustrated but very keen and impressed newbie C2 user
Luke Studley
-
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]
