Sure. This is a custom tag that I wrote originally under CFAS 4.5.1SP2 and
had to change it when I ran into the bug. The interface to the tag is
somewhat parochial to our system, but you should get the idea for how to
call the scripting component. To use it as is, you'll need to instantiate
all of the Request level variables that the tag expects to see.

+++++++++++ CUT HERE +++++++++++++

<CFSETTING ENABLECFOUTPUTONLY="Yes">
<!--- 
NAME:                   RWDEW_applyTransform.cfm 
AUTHOR:                 Rob Blitz
DATE:                   Oct 2001 
APPLICATION:    
PURPOSE:                Apply and XSLT transformation on an DOM node or an
XML document
USAGE:                  CONTENTXML:  (optional, string) xml fragment
                                TRANSFORMNAME: (required, string) name of
the
                                TRANSFORMPATH: (optional, string) name of
the directory under the "transform" directory
                                        where the transform file specified
by TRANSFORMNAME is located. By default, the 
                                        TRANSFORMPATH is equivalent to the
value of Request.deliveryContext.formatID 
                                XSLPARAMSTRUCT: (optional, CF structure) Key
value pairs of param names/values that
                                        are sent into the XSL stylesheet.
The param values must be simple data types.
                                OUTPUT: (required, string) name of a
variable in the caller's scope into which the output                    
                                        should be placed.
ASSUMPTIONS:    
                Dependencies: msxmlXSLTWrapper.wsc Scripting COM object that
is a workaround for a bug in CF5 where
                                the FreeThreadedDOM object of MSXML fails.
NOTE:                   
--->
<CFPARAM NAME="Attributes.TRANSFORMPATH"
DEFAULT=#Request.deliveryContext.formatID#>
<CFPARAM NAME="Attributes.OUTPUT" DEFAULT="">
<CFPARAM NAME="xslParamsProvided" DEFAULT="false">

<!--- do some interface error checking --->             
<CFIF NOT IsDefined("Attributes.CONTENTXML") OR NOT
Len(Attributes.CONTENTXML)>
        <CFTHROW TYPE="RWDEW.System" DETAIL="The RWDEW_applyTransform tag
requires a CONTENTXML attribute of non-zero length to be specified.">
</CFIF>

<CFIF NOT IsDefined("Attributes.TRANSFORMNAME")>
        <CFTHROW TYPE="RWDEW.System" DETAIL="The RWDEW_applyTransform tag
requires that a TRANSFORMNAME be specified.">
</CFIF>

<!--- check the parameter structure --->                
<CFIF IsDefined("Attributes.XSLPARAMSTRUCT")>           <!--- it has to be a
structure --->                  
        <CFIF NOT IsStruct(Attributes.XSLPARAMSTRUCT)>
            <CFTHROW TYPE="RWDEW.System" DETAIL="The RWDEW_applyTransform
tag requires that the XSLPARAMSTRUCT be a ColdFusion structure data type.">
        </CFIF>
        <CFLOOP COLLECTION=#Attributes.XSLPARAMSTRUCT# ITEM="param">
                <CFIF NOT
IsSimpleValue(Attributes.XSLPARAMSTRUCT[param].value)>
                        <!--- parameter values have to be simple data types
--->
                    <CFTHROW TYPE="RWDEW.System" DETAIL="The
RWDEW_applyTransform tag requires that the values of parameters passed to
the XSL stylesheet through XSLPARAMSTRUCT be simple data types.">
                </CFIF>
        </CFLOOP>
        <CFSET xslParamsProvided=true>
</CFIF>

<!--- create the XSLT Wrapper object --->
<CFOBJECT TYPE="COM"
         NAME="msxslw"
         CLASS="msxmlXSLTWrapper.WSC"
         ACTION="CREATE"
         CONTEXT="INPROC">

<!--- load the content --->
<CFSET msxslw.contentXML=Attributes.CONTENTXML>
<CFIF Len(msxslw.errorMessage)>
        <CFTHROW TYPE="RWDEW.System" DETAIL=#tagError#>
</CFIF>

<!--- set the stylesheet --->
<CFSET
msxslw.stylesheet=Request.FSTransformRoot&"\"&Attributes.TRANSFORMPATH&"\"&A
ttributes.TRANSFORMNAME>
<CFIF Len(msxslw.errorMessage)>
        <CFTHROW TYPE="RWDEW.System" DETAIL=#tagError#>
</CFIF>

<!--- set the parameters (if any.) --->
<CFIF xslParamsProvided>
        <CFLOOP COLLECTION="#Attributes.XSLPARAMSTRUCT#" ITEM="paramName">
                <CFSET msxslw.addParameter(
Attributes.XSLPARAMSTRUCT[paramName].name,
        
Attributes.XSLPARAMSTRUCT[paramName].value,
        
Attributes.XSLPARAMSTRUCT[paramName].namespace)>
        </CFLOOP>
</CFIF>

<!--- run the transform --->
<CFSET output=msxslw.applyTransform()>
<CFIF Len(msxslw.errorMessage)>
        <CFTHROW TYPE="RWDEW.System" DETAIL=#tagError#>
</CFIF>

<!--- strip a possible xml declaration tag coming from the handler that was
just called  --->
<CFSET output=REReplaceNoCase(output,"<\?.*\?>(.*)","\1","ALL")>

<CFIF Trim(Attributes.OUTPUT) NEQ "">
        <!--- pass the generated output to the calling module if an output
variable was specified --->
        <CFSET "Caller.#Attributes.OUTPUT#"=output>
<CFELSE>
        <!--- otherwise, just output the value right here --->
        <CFOUTPUT>#output#</CFOUTPUT>
</CFIF>
<CFSETTING ENABLECFOUTPUTONLY="NO">

++++++++++ STOP CUTTING HERE +++++++++++++

Rob Blitz
Team Leader
Web Application Development Team
RWD Technologies, MIS
410.884.5063 (Office phone)
410.884.2749 (Office fax)
39:12:42.426N 76:51:42.808W (ICBM)

-----Original Message-----
From: tom dyson [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, February 12, 2002 11:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [cf-xml] Workaround for XSLT Stylesheet processor error

Rob, this is excellent. Could you send us an example of how to call it from
ColdFusion?

Thanks very much

Tom

-----------------+
tom dyson
t: +44 (0)1608 811870
m: +44 (0)7958 752657
http://torchbox.com

> Someone posted a while ago about the MSXML XSLT processor object failing
in
> CF5. I've run into the same problem. Per someone's suggestion, I wrote a
> simple wrapper object as a Windows Scripting Component. I'm no WSC guru,
so
> if someone sees something wrong, please share.... The WSC code is pasted
in
> below.
> 
> This wrapper was just meant to work around the XSLT Processor problem. It
> just lets you apply a stylesheet to some content xml that you pass to it.
> The component populates an "errorMessage" property for you to check from
> within your CF code after various operations.
> 
> I don't like having to wrap functionality this way because it pushes the
> problem into the "configuration space". That makes a system more
susceptible
> to failure and more difficult to manage. But, until Macromedia gets its
sh*t
> together and fixes their COM facilities, this will have to do.
> 
> Rob


-----------------------+
cf-xml mailing list
list: [EMAIL PROTECTED]
admin: [EMAIL PROTECTED]
home: http://torchbox.com/xml

-----------------------+
cf-xml mailing list
list: [EMAIL PROTECTED]
admin: [EMAIL PROTECTED]
home: http://torchbox.com/xml

Reply via email to