RE: [xsl] extending xsl with javascript

["Scott Trenda" <Scott.Trenda@xxxxxxxx>]

Hey April,

No problem. If I'm understanding your restrictions correctly, there's
actually a faster and more direct way to do what you're looking for. Try
loading the XML document with this:

function loadURL (url) {
  var xmldoc = (document.implementation &&
document.implementation.createDocument) ?
                document.implementation.createDocument("", "", null) :
                window.ActiveXObject ? new
ActiveXObject("MSXML2.DOMDocument") : null;
  if (xmldoc) {
    xmldoc.async = false;
    xmldoc.load(url);
    return xmldoc;
  }
}

Then, are you performing the XSL transformation on the client-side,
within Javascript? (It sounds like you are, if you're modifying the DOM
to fake parameters.) If so, why not set the parameters directly on your
XSLT object? Mozilla's method is XSLTObj.setParameter(), and IE's method
is XSLTObj.addParameter(). That sounds like it'd be much easier than DOM
manipulation. :P

And this is just personal bias, but I'd think that transforming the XML
to a DOMDocument object (transformToDocument() in Mozilla,
transformNodeToObject() in IE) and doing
div.appendChild(resultObject.documentElement) would be cleaner/faster
than setting the innerHTML. :)


(This reply is probably on the border regarding relevancy to XSL-List
topics, so reply directly to me if you need to.)

~ Scott


-----Original Message-----
From: april@xxxxxxxxxxx [mailto:april@xxxxxxxxxxx]
Sent: Thursday, November 08, 2007 2:10 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] extending xsl with javascript

Hi Scott & Charles - Thank you!

Scott - I suspect you are right that I won't be able to acess the window
object during the time of XSL processing. My kludge has been to use
HTTPRequest to load the xml document, create/set attributes that act as
command line parameters, perfom the transformation, and then attach the
result to a <div>. The top level XSL looks like:

<xsl:template match="/">
  <!-- Get Input Variables   -->
  <xsl:variable name="DashboardMode"><xsl:value-of
select="//*/@templateMode"/></xsl:variable>
  <xsl:variable name="SelectedManager"><xsl:value-of
select="//*/@selectedManager"/></xsl:variable>
  <xsl:variable name="SelectedService"><xsl:value-of
select="//*/@selectedService"/></xsl:variable>
  <xsl:variable name="SelectedFunction"><xsl:value-of
select="//*/@selectedFunction"/></xsl:variable>

<!-- Top Level 'Select Case'  -->
<xsl:choose>
 <!-- Service Manager Dashboard -->
 <xsl:when test="$DashboardMode='Manager'">
   <xsl:call-template name="ManagerDashboard" >
    <xsl:with-param name="manager"><xsl:value-of
select="$SelectedManager"/></xsl:with-param>
    <xsl:with-param name="function"><xsl:value-of
select="$SelectedFunction"/></xsl:with-param>
   </xsl:call-template>
 </xsl:when>
 <!-- Service Dashboard -->
 <xsl:when test="$DashboardMode='Service'">
   <xsl:call-template name="ServiceDashboard" >
     <xsl:with-param name="service"><xsl:value-of
select="$SelectedService"/></xsl:with-param>
     <xsl:with-param name="function"><xsl:value-of
select="$SelectedFunction"/></xsl:with-param>
   </xsl:call-template>
  </xsl:when>

  <xsl:otherwise>
    <xsl:apply-templates mode="Error" select="/"/>
  </xsl:otherwise>
</xsl:choose>

</xsl:template>


It's pretty ugly (and needs to be refactored), but it works! The
challange to this app was to keep the depolyment simple (i.e., minimize
the number of files, this has a minimum of three: html, xml, and xsl)
and reasonably self contained. My customer develops a niche industry
application and installation of xml processing engines would have been
frowned upon. Thanks all for your help.

Regards,
April