This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Mozilla XML > August 2005 > Accessing the original XML DOM after browser-applied XSL transformation?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Accessing the original XML DOM after browser-applied XSL transformation?
|
|
| blblack 2005-08-17, 11:24 pm |
| I'm just now getting ramped up on XML + XSLT stuff with the intent of
possibly using it in a new corporate web app, having come from
previously doing just (X)HTML+CSS, so bear with me.
The new app's web interface is being designed around the XMLHttpRequest
concept - load the user interface page once when you log in, and then
stay there and dynamically load new content as they click around the
page type of thing. (Yeah I know there's a buzzword for it, but I'm
trying to avoid it :) ).
In any case, what I'd *really* like to be able to do is:
1) Send the initial page as a pure XML document of my own structure,
with an associated static XSL containing a bunch of nested transforms
which transform it into XHTML 1.1 at the browser.
2) Have the javascript xmlhttprequest-based interaction code in this
page pull fresh XML data from my server based on the same DTD/namespace
as the original page I sent.
3) Use DOM or something similar to insert/append/replace chunks of the
original XML document with the new content.
4) The new content should be correctly transformed to XHTML in the
browser just as if it were part of the original document.
When I got to step 3 is of course where the plan failed.
window.document refers to the resulting XHTML from after the XSL
transformation. "View Source" shows my original XML, but the DOM
Inspector (and as near as I can tell, anything I can see from
javascript-land) only shows the transformed XHTML document.
Is it just plain impossible? Or am I missing some interface/object
that I failed to find, which would allow me to manipulate the
pre-transform XML? And if there is, will the existing transformation
to XHTML automatically stay in sync with the XML tree changes?
The only thing I saw that might be close would be to manually load the
xsl a second time from inside javascript and do the transform manually,
but that would also mean that I'd have to manually maintain references
between the XML and HTML trees to know where to map the output to, and
it would screw up XSL transforms that depended on the context of
elements which are not part of the fresh fragment being
loaded/transformed.
| |
| Axel Hecht 2005-08-18, 7:54 pm |
| blblack wrote:
> I'm just now getting ramped up on XML + XSLT stuff with the intent of
> possibly using it in a new corporate web app, having come from
> previously doing just (X)HTML+CSS, so bear with me.
>
> The new app's web interface is being designed around the XMLHttpRequest
> concept - load the user interface page once when you log in, and then
> stay there and dynamically load new content as they click around the
> page type of thing. (Yeah I know there's a buzzword for it, but I'm
> trying to avoid it :) ).
>
> In any case, what I'd *really* like to be able to do is:
>
> 1) Send the initial page as a pure XML document of my own structure,
> with an associated static XSL containing a bunch of nested transforms
> which transform it into XHTML 1.1 at the browser.
>
> 2) Have the javascript xmlhttprequest-based interaction code in this
> page pull fresh XML data from my server based on the same DTD/namespace
> as the original page I sent.
>
> 3) Use DOM or something similar to insert/append/replace chunks of the
> original XML document with the new content.
>
> 4) The new content should be correctly transformed to XHTML in the
> browser just as if it were part of the original document.
>
> When I got to step 3 is of course where the plan failed.
> window.document refers to the resulting XHTML from after the XSL
> transformation. "View Source" shows my original XML, but the DOM
> Inspector (and as near as I can tell, anything I can see from
> javascript-land) only shows the transformed XHTML document.
>
> Is it just plain impossible? Or am I missing some interface/object
> that I failed to find, which would allow me to manipulate the
> pre-transform XML? And if there is, will the existing transformation
> to XHTML automatically stay in sync with the XML tree changes?
>
> The only thing I saw that might be close would be to manually load the
> xsl a second time from inside javascript and do the transform manually,
> but that would also mean that I'd have to manually maintain references
> between the XML and HTML trees to know where to map the output to, and
> it would screw up XSL transforms that depended on the context of
> elements which are not part of the fresh fragment being
> loaded/transformed.
>
Does IE expose the source XML to js in the result doc somehow? If so, is
that documented anywhere?
Axel
| |
|
|
|
|
| Axel Hecht 2005-08-19, 4:25 am |
| Christian Biesinger wrote:
> Martin Honnen wrote:
>
> "readonly" here only means that you can't do "document.XMLDocument =
> foo;", doesn't it? It doesn't necessarily mean that you can't change the
> DOM.
Yes.
Btw, as this pops up on other places, too, Ben has filed
https://bugzilla.mozilla.org/show_bug.cgi?id=305121.
Axel
| |
| Martin Honnen 2005-08-19, 7:38 pm |
|
Christian Biesinger wrote:
> Martin Honnen wrote:
>
>
>
> "readonly" here only means that you can't do "document.XMLDocument =
> foo;", doesn't it? It doesn't necessarily mean that you can't change the
> DOM.
When I wrote that I had some recollection that I had long ago attempted
to change the DOM and it would not work. But I have tried now and you
can change the DOM of document.XMLDocument. But an automatic update of
the result document rendered in the browser does not happen, one needs
to run the transformation using the MSXML methods (e.g. tranformNode)
and then use IE DOM stuff (e.g. innerHTML, insertAdjacentHTML) to have
the string result of transformNode parsed and inserted into IE's HTML
DOM document.
--
Martin Honnen
http://JavaScript.FAQTs.com/
| |
| Axel Hecht 2005-08-19, 7:38 pm |
| Martin Honnen wrote:
>
>
> Christian Biesinger wrote:
>
>
> When I wrote that I had some recollection that I had long ago attempted
> to change the DOM and it would not work. But I have tried now and you
> can change the DOM of document.XMLDocument. But an automatic update of
> the result document rendered in the browser does not happen, one needs
> to run the transformation using the MSXML methods (e.g. tranformNode)
> and then use IE DOM stuff (e.g. innerHTML, insertAdjacentHTML) to have
> the string result of transformNode parsed and inserted into IE's HTML
> DOM document.
>
Which is actually pretty cool, as you don't end up transforming over and
over for multiple changes to the DOM on the one side, on the other side,
you don't mess with content in inputs, or other js modifications to the
DOM that once got js generated.
Axel
| |
| blblack 2005-08-23, 8:27 pm |
| It would be far cooler, IMHO, if the XSLT processor automatically
updated the transformation output on each change to the source XML DOM,
but was designed to do so without retransforming the entire document on
every change. If I change a given node and its children within the
source XML, the XSLT processor should be capable of understanding
exactly what elements should be affected within the output DOM. The
declarative structure of XSLT and the use of XPath seems to almost beg
for this treatment. It seems within the realm of reasonable design,
and would really unleash the power of XML+XSLT in the browser.
Imagine, for a simple example, that I can send an XML document which
contains:
[...]
<somelist>
<anitem abc='fark'>foo</anitem>
<anitem abc='bar'>xxx</anitem>
</somelist>
[...]
Along with a static "<?xml-stylesheet ...>" reference at the top of the
document to a static XSL transform for the entire page to generate
complex XHTML[+CSS] in the browser.
And then, with javascript code (which was generated from the XSL file -
that can be confusing), I can access the source dom and inject or
remove <anitem>'s from the list and the XHTML page rendering stays
updated.
Of course there's the obvious downside of possibly infinite loops if
javascript makes a source DOM change which triggers a fragment
re-transform that causes the execution of javascript which makes a
source DOM change, etc, but the smart programmer would easily avoid
those scenarios.
But the results, I feel, are huge. You would no longer have to
manipulate HTML display code and style attributes from javascript. You
can simply manipulate the real XML representation of your actual data,
and let XSLT worry about *all* of the presentation details. This
greatly simplifies the javascript code.
I only wish I knew enough about Gecko to implement it myself :) For
some web-apps, the amount of saved work is almost enough to justify
writing the support code in Gecko.
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|