ahh. maybe this is my problem. in msxml3 (or 4) do I have to load the
additional msxml parser to get the values out?
you need to if you want to get a dom that you can handle as a nodeset.
If for example you had
var xmlnodes;
xmlnodes = "<test>is a test</test>";
return xmlnodes
what you would end up with on the other end is
<test>is a test</test> which you should be able to get ahold
of using your xsl:value-of
I was thinking more along the lines of, a description of what one wants
to do with examples etc. and it could be that various people on this
list would say - "do this instead"
snip
<xsl:template match="/level2">
<xsl:value-of select="msxsl:test(.)"/>
</xsl:template>
<msxml:script name="JScript" implements-prefix="test">
function test(node)
{
if(node.length > 0 && node.type != "object")
// TIME TO PARTY
}
I'm supposing it would be better to have
<xsl:template match="level2">
<xsl:if test="* or text()">
<xsl:value-of select="test:test(.)"/>
</xsl:if>
</xsl:template>
<msxml:script name="JScript" implements-prefix="test">
function test{node}
{
test="my string";
return test;
}
</msxml:script>
my earlier example was probably not a good one, in that it caused you to
assume what you should have was <xsl:value-of select="msxml:test(.)"/>
when what you should have is test:test(.) - test being the namespace
prefix and also the name of the function in this case, this is why
msxml:script says implements-prefix="test".
And of course one needs to return some value at the end of the function
Again it is difficult to give suggestions without examples, if there
is
something in these files that is proprietary than make an abstract
case
and example that requires the same handling.
that is obviously abstract as the real thing is not mine to write out!
Its just a passing problem of nodes. Some of those nodes have to exit
the program by way of a javascript function and all I get is a 0 or 1
length 'object' that I can't do anything with - if I do node.nodeType
I get 'undefined'.
See one thing is it's rather unclear what you want the whole thing to
do, you say you want to start a javascript process up but the reason? If
the reason was given we might indeed find that it was something that did
not require you starting javascript, on the other hand it might be that
it does require some process external to xslt, and we could say, well
what you need to do is the following in the application which calls the
xslt. That is to say give some design guidance.
It is at any rate not considered a good thing to have scripted
extensions inside of ones xslt as it interferes with cross-processor
portability and also could make life difficult for future maintainers of
your application. Consider if for example someone like myself had to
work with this application at some point, I would probably want to
rewrite the whole thing from the bottom up to remove the necessity of
dealing with jscript inside of my xslt. Or if the company hires somebody
who has learned xslt working mainly with xalan or saxon or the like, if
all processing is actually done inside of a scripted extension their
experience is rendered useless. Many of these issues came up in the
debate over xslt 1.1 which was never completed as a rec, a good synopsis
of the problems caused by scripted extensions can be found at
http://www.biglist.com/lists/xsl-list/archives/200103/msg00000.html
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list