cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <>
Subject Re: XSP Encoding Behavior Question (Was "Alternate Provider")
Date Tue, 11 Jul 2000 15:06:21 GMT
On Tue, 11 Jul 2000, Kip Hampton wrote:

> Again, it comes back to wanting to include chunks of dynamically created
> markup into the current document. The example you gave earlier in this
> thread for pulling in the $cgi params works great and it really got me
> started with XSP. But that method assumes that there is one form field
> per element and all I'd want to do is edit the text node which makes it
> unrealistic for all but the most simple cases.
> Now, I played around with this quite a bit yesterday and *please*
> correct me if I'm wrong, but given a var $snippet in your XSP doc that
> holds the string "<a>Text</a>" you'd have to:
> 1. Parse $snippet with XML::*::Parser
> 2. Pass the resulting $snippet_tree through an arguably complex,
> certainly verbose, routine to generate the <xsp:element>s maintaining
> all the approprate attrs but since you cannot set the TagName attribute
> you have to invent some bogus name, crossing your fingers that neither
> the arbitrary "name" (DOM TagName at stage two) nor the equally bogus
> "actual_name" (the snippet's /real/ DOM TagName) attributes you choose
> won't conflict anywhere.
> 3. Pass the whole doc through an intermediate XSLT/XPathScript to
> transform <arbitrary_secret_name
> actual_name="a">Text</arbitrary_secret_name> back into <a>Text</a>.
> 4. Finally, pass *that* result to the rest of your style output chain.

Well OK, you _could_ potentially hack direct into the XSP code using the
$document and $parent vars, which would look like:

my $el = $document->createElement(...);
$parent->appendChild($el); $parent = $el;

And obviously insert all your DOM code in there for creating and inserting
fragments... But "yuck"!

So you want some way of editing XML in the web browser, and passing it
back to the server, is that correct? If thats what you're after I suggest
you first take a look at and
let me know if that fits your needs to some extent. If it does, we can
work on incorporating that into AxKit. I believe that the Cocoon team are
working on something similar based on the Java "XMLForm" library.

> All that just to include a little snippet of markup. Yuck. There's gotta
> be a better way. . .
> Now, please don't misunderstand, Matt. I'm not downing your
> implementation of XSP. As far as I can tell, it follows the spec to the
> letter. The weakness is in the fact that XSP has no equivalent to XSLT's
> document() or import() funtions and, further, makes working around that
> weakness problematic to the point of grief. Even going against spec and
> hacking in some sort of <xsp:fragment> tag won't work since the
> <xsp:expr> you'd use to pass the $snippet to it would stringify the
> markup. . . 

Well the problem is that XSP is already parsed into a DOM builder, it's
not parsed on a per-hit basis. And parsing to DOM is slow. So adding in
another stage where you parse a fragment into a DOM fragment, and then
insert into the main tree is going to be slow. There's got to be a better
way, as you say.

> Taking a step back, am I right in thinking that this sort of "include a
> fragment" functionality is important?

I'm not really sure. One thing of significance is that there is nothing
unique to AxKit's XSP implementation of this, so its going to be worth
discussing it with the cocoon folks to see if they have a solution, or
whether or not they think its bunk. Or perhaps even Cocoon has something
in their implementation that covers this (they do have some functions in
their API that I haven't emulated yet).


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability. | AxKit:

View raw message