[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Ian,
At 12:34 PM 3/29/2006, you wrote:
This makes much more sense than the (broken) code you posted earlier.
Note that this XSLT is the same as
The addition of the otherwise-gratuitous xsl:text elements allows us to format this for easier reading; it also elucidates a bit of what's going on at this point in your XSLT:
Notice that none of this has anything to do with Javascript. It's only job is to construct a node hierarchy containing certain elements and attributes with certain values. Those values happen to be syntactically-correct Javascript, but the XSLT engine doesn't know that and doesn't have to.
Yup!
Yup.
What you've posted this time isn't wrong and should work in both processors. It's just easier to see in XSLTProc.
What you posted before was wrong (and confusing :-).
Just remember that although the HTML representation of your data set that your transformation is creating may have Javascript in it, that in itself is of no particular significance to the transformation ... to XSLT, the Javascript could equally well be FORTRAN or BASIC or that ancient (though still popular) language "English" (or German or French or Japanese), and all would be the same.
Anyway, it's good we can help.
Re: [xsl] XSL template "namespace" problem
Subject: Re: [xsl] XSL template "namespace" problem From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Wed, 29 Mar 2006 14:37:58 -0500 |
Ian,
At 12:34 PM 3/29/2006, you wrote:
... I know the Javascript is really a tier unto its own, and shouldn't be able to be processed via XSLT. I went through and tried some more examples, and embedded XSL code inside of HREFs weren't actually possible, but I was able to get modified Javascript calls via XSL through the <xsl:attribute> tag. Whether this is *proper* or not is, of course, up for debate, but xsltproc parsed it and gave output, so I assumed that it was proper. One snippet of XSLT code I'm using as an example is:
<A NAME="linkone"><xsl:attribute name="HREF">javascript:process('linkone',<xsl:value-of select='/rootnode/value'/>)</xsl:attribute>Click me, value is: <xsl:value-of select="/rootnode/value" />.</A>
This makes much more sense than the (broken) code you posted earlier.
Note that this XSLT is the same as
<A NAME="linkone"> <xsl:attribute name="HREF"> <xsl:text>javascript:process('linkone',</xsl:text> <xsl:value-of select='/rootnode/value'/> <xsl:text>)</xsl:text> </xsl:attribute> <xsl:text>Click me, value is: </xsl:text> <xsl:value-of select="/rootnode/value" /> <xsl:text>.</xsl:text> </A>
The addition of the otherwise-gratuitous xsl:text elements allows us to format this for easier reading; it also elucidates a bit of what's going on at this point in your XSLT:
an A element is appended to the result tree a NAME attribute is appended to the A element a value of "linkone" is assigned to the @NAME an HREF attribute is appended to the A element a value is assigned text: "javascript:process('linkone'," the value of /rootnode/value text: ")" text is appended inside the A element: "Click me, value is: " next, the value of /rootnode/value is appended next, text is appended: "."
Notice that none of this has anything to do with Javascript. It's only job is to construct a node hierarchy containing certain elements and attributes with certain values. Those values happen to be syntactically-correct Javascript, but the XSLT engine doesn't know that and doesn't have to.
It literally produces the following output from xsltproc (of course, again, taken out of context.. I don't want to spam the list with code)
<A NAME="linkone" HREF="javascript:process('linkone',10)">Click me, value is: 10.</A>
Yup!
(This is assuming that the XML file its using has a <rootnode><value>10</value></rootnode> entry.)
Yup.
Its stuff like this that is confusing. Technically, I can never read ALL there is to know about XSLT while I'm learning, so I usually try examples to see if what I learned in theory can be applied on "real examples". I.E. stuff that I want to do with this type of technology. If xsltproc works, and IE works on what I've produced, there's nothing really telling me its "wrong". (Until, of course, I mention it on a mailing list like this one. :) )
What you've posted this time isn't wrong and should work in both processors. It's just easier to see in XSLTProc.
What you posted before was wrong (and confusing :-).
Regardless, I really appreociate the time you guys have given me in replying with great ways to further my education in the field on the "right track". I'll follow as many of those links as possible, and look for other links regarding embedded Javascript or "how not to do it."
Just remember that although the HTML representation of your data set that your transformation is creating may have Javascript in it, that in itself is of no particular significance to the transformation ... to XSLT, the Javascript could equally well be FORTRAN or BASIC or that ancient (though still popular) language "English" (or German or French or Japanese), and all would be the same.
Anyway, it's good we can help.
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XSL template "namespace" , Michael Kay | Thread | Re: [xsl] XSL template "namespace" , Ian Bonnycastle |
RE: [xsl] Filtering out duplicates , Don Smith | Date | RE: [xsl] XSL template "namespace" , Wendell Piez |
Month |