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.
There is not necessarily any *real* protocol. Think of this as a cheat's way
of making a simple (or not so simple) java call from within XSLT, that
allows you to return a chunk of XML anywhere in your XSLT document.
Here's another quick made up e.g.
<xsl:value-of select="document('hello:/World')/>
Try this in your stylesheet and you'll probably get some sort of URL
unrecognized protocol error. You can't "just use http" as this is not a real
document - it's just a meaningless string - until you add a custom resolver
like...
public class HelloWorldURIResolver implements URIResolver {
public javax.xml.transform.Source resolve(java.lang.String str, g.String
str1) throws javax.xml.transform.TransformerException {
if ( str.equals("hello:/World") ) {
String msg="<?xml version="1.0" ?> <h1>Hello World</h1>";
return new StreamSource(new StringReader(msg));
}
return null;
}
}
[apologies 4 mistakes - off top of head code]
If you register this URIResover and run it it should pass that mini bit of
XML. Now let your imagination run wild and think of all the free form
strings you could pass into document() to get out all sorts of things (in
XML form) like:
JMS messages
EJB method return values
Beans Marshalled to XML (by castor or JAXB)
Even dB queries
Anything - anything!!!
As well as your straight http:// and file:// type documents - you
could even override these protocols to provide a smart local cache or
redirect mechanism.
Much of this could be replicated by using extension elements - but not with
the same flexibility or ease (and portability) I don't think.
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 ;-)
All the best
Luke
-----Original Message-----
From: Robert Koberg [mailto:[EMAIL PROTECTED]]
Sent: 06 December 2001 02:43
To: [EMAIL PROTECTED]
Subject: 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
----- Original Message -----
From: "Luke Studley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, December 05, 2001 4:18 PM
Subject: RE: Inserting / Comining XML data
> Not at all!
>
> I am wanting to use my own URIResolver so I can define my own or arbitrary
> 'protocols'. Here is an example:
>
> <xsl:variable name="nextMessageSet"
>
select="document('jbossmq://localhost:1099/QueueConnectionFactory#MyXMLTestQ
> ueue?max=10')"/>
>
> Now it doesn't matter what text string goes in the document argument - as
> long as your URIResolver knows how to process it into some form of XML. So
> my URI processor might implement a stack of protocols that know how to do
> different things and if it doesn't match one it defaults to the regular
url
> patterns. E.g for the example above my resolver might know how to handle
> this string by connecting to a jboss JMS message queue and retrieve a
> maximum of 10 messages and return it as a chunk of XML - that I can then
use
> in my stylesheet.
>
> This is particularly powerful when you couple it with dynamic xpath
> expressions (like with saxon:expression). It is nice doing the processing
> this way as you don't have to make any assumptions in the data setup about
> how your stylesheet processing might go (hence pull MVC - your model
really
> doesn't need to know anything about the view). In particular I use it as
> part of a lazy loading strategy - rather than pre-loading an entire XML
> document generated from multiple dBs and App servers before XSLT
processing
> I use the document() function to selectively load what is required
depending
> on the processing path that is actually followed in the stylesheet.
>
> Works for me anyhow ;-)
>
> Luke
>
>
>
> -----Original Message-----
> From: Robert Koberg [mailto:[EMAIL PROTECTED]]
> Sent: 05 December 2001 23:55
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: 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:
> <boo>boo</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
>
>
>
>
> ---------------------------------------------------------------------
> 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]>
