Is it doable in some single method?
If this analogy may help I'm seeking Gecko's transformToFragment /
transformToDocument functionality.
I'm seeking for a solution for MSXML 3 or higher.
--
Joe Fawcett (MVP - XML)
Yes, with transformNodeToObject called instead of transformNode where
you need to create the result DOM document first e.g.
var resultDoc = new ActiveXObject('Msxml2.DOMDocument.3.0');
inputDoc.transformNodeToObject(stylesheetDoc, resultDoc);
Make sure all documents involved belong to the same MSXML version (e.g.
in the above sample MSXML 3).
--
Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Do you have a working sample of this? because transformNodeToObject was
explored as well before I asked.
on trying to appendChild(resultDoc) it gives "interface not supported".
Rather than check my errors it would be more easy to compare with a
proper usage.
To avoid this branch of possibilities: the MSIE's part of the
initialisation block looks like:
...
INIT:
do {
try {
XSL = new ActiveXObject('Msxml2.DOMDocument.'+N+'.0');
XML = new ActiveXObject('Msxml2.DOMDocument.'+N+'.0');
DOC = new ActiveXObject('Msxml2.DOMDocument.'+N+'.0');
break INIT;
}
catch(e) {
--N;
continue INIT;
}
} while (N>2);
if (DOC == null) {
flagError(
'Automation server cannot create object\n' +
'ActiveX instantiation is blocked by security settings ' +
'or MSXML version is too old - 3.0 or higher is required.');
}
...
This way either all objects initialized with the same ProgID or not
init at all (goes to error handling).
On the test machine the lowest supported version is used (3) and XML,
XSL and DOC are successfully created.
With XSL and XML loaded and parsed the next step currently looks like:
source.transformNodeToObject(XSL, DOC);
return DOC;
With the code on page:
document.body.appendChild(transResults);
gives error "No such interface supported" on IE6 which is tracked down
to appendChild method.
At the same time transResult.documentElement.tagName properly shows the
root of the fragment (ol in my case).
> With XSL and XML loaded and parsed the next step currently looks like:
> source.transformNodeToObject(XSL, DOC);
> return DOC;
>
> With the code on page:
> document.body.appendChild(transResults);
>
> gives error "No such interface supported" on IE6 which is tracked down
> to appendChild method.
That does not work if document.body is the body of an HTML DOM document.
The XML DOM implementation (of MSXML) and the HTML DOM implementation
(of IE/MSHTML) are separate implementations, you are not able to move
nodes from an XML DOM document to a HTML DOM document. If your intention
is to transform XML to HTML with XSLT then with IE you are bound to use
transformNode to get a string result and insert that string into the
HTML document with innerHTML or insertAdjacentHTML.
And note that even with Mozilla's DOM implementation you should consider
using importNode instead of simply moving nodes from one document to
another.
While waiting for responces I looked on Sarissa doing on this matter.
<http://sarissa.sourceforge.net/doc/overview-summary-sarissa.js.html>
You are seem right: with IE you are either happy with
insertAdjacentHTML or you are using rather ugly hacks like the one on
Sarissa - to bring appendChild back to life.
Taking into account that to get rid off insertAdjacentHTML was the
original purpose of our library remodeling - it puts a rather hard
choice :-) :-(
Thanks everyone.
but with MSXML tools.
> What happens if you display DOC.xml?
I see the properly transformed fragment, the problem that it's not
usable for HTML DOM methods.
> For a full example see the SDK:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/ece045e3-85b3-46ed-85b4-8532f076ea79.asp?frame=true
transformNodeToObject is the method I tried first - as I said in
another post it is not usable for HTML DOM.
Thank you for your time.
That's a separate issue so a separate answer. I'm not talking about
"move nodes from an XML DOM document to a HTML DOM document". All I
want is to move nodes from one HTML document to another HTML document.
Don't forget that while both XSL template and XML data are XML
documents, the transformation result is whatever you wanted it to be:
XML, HTML, VML, SVG, plain text etc. It even doesn't have to be
well-formed, not talking about being valid.
my XSL test template is
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output
omit-xml-declaration="yes"
method="html"
encoding="ISO-8859-1"
media-type="text/html" />
<xsl:template match="/">
<ol>
<xsl:for-each select="data/item">
<li><xsl:value-of select="word"/></li>
</xsl:for-each>
</ol>
</xsl:template>
</xsl:stylesheet>
my XML test data is
<?xml version="1.0" encoding="ISO-8859-1"?>
<data>
<item>
<word>One</word>
</item>
<item>
<word>Two</word>
</item>
<item>
<word>Three</word>
</item>
</data>
which results after transformation into _HTML_ fragment
<ol>
<li>One</li>
<li>Two</li>
<li>Three</li>
</ol>
There is not a smell of XML in the transformation result and most of
UA's do agree with it - except IE that respects <output> processing
instruction during processing but acts like an idiot right after that.
Sorry, I did not mean to make this thread as a "Microsoft criticism" of
any kind. I'm just upset that among dozens and dozens of MSXML methods
there is not a single one for such trivia.
For anyone hitting the same problem: I stopped on a workaround using
virtual DOM element:
...
var MSHTML = document.createElement('div');
MSHTML.innerHTML = source.transformNode(XSL);
return MSHTML.firstChild;
...
It is not a full-scaled hack like in Sarissa so it doesn't take care of
more complicated cases - a set of sibling elements, mal-formed fragment
and so on.
For my practical purposes though I fits well as it will be a
well-formed single parent out of a transformation (list, table, shape).
For such trivial cases it lets to bypass the IE's limitation with the
minimum overheat.