我最初喜欢 @Orangepips 对 @Anooj 的回答的原因在于,每次您在 CFM 中包含 <script> 时都需要单独的 Javascript 块,因此更便于未来维护。
然而,经过几分钟的思考,结合这两个答案很容易消除这种情况。这为您提供了模块化,以便您寻求今天的开发和未来的维护 - PLUS 作为最佳实践,可以为您提供静态 Javascript 的隔离和缓存,以降低您的 CF 页面请求大小和响应速度。
基本上,您应该创建一个基于 CF 的外观,您将在每次需要 Javascript 功能时包含或调用该外观。在我的示例中,我将外观设置为一个可调用函数,您可以将 JS 参数传递给该函数(正如 @Orangepips 所暗示的那样),以便严格控制传递给 JS 的变量。
(顺便说一句,作为最佳实践,我倾向于将所有内联 JS 放入变量中,然后将其填充到 CFHEADER 中,以确保它位于页眉中。)
dosomething.js
<script type='text/javascript'>
<!-- assert vars were passed in -->
if ( source == undefined )
alert("Developer error: source not defined.");
return;
}
if ( urlpath == undefined )
alert("Developer error: urlpath not defined.");
return;
}
<!-- do some js stuff --->
alert('source: ' + source + ", urlpath: " + urlpath );
</script>
udf.cfm:
<cffunction name="doSomething" output="true" returntype="void">
<cfargument name="source" required="true" />
<cfargument name="urlpath" required="true" />
<cfsavecontent variable="header">
<script type="text/javascript">
<!-- var init -->
<cfoutput>
var source = '#arguments.source#';
var urlpath = '#arguments.urlpath#';
</cfoutput>
</script>
<script language="JavaScript" type="text/javascript" src="dosomething.js"></script>
</cfsavecontent>
<cfhtmlhead text="#header#">
</cffunction>
应用程序.cfm
<cfinclude template="udf.cfm">
view1.cfm:
<cfoutput>#doSomething("view 1", "http://myurl/view1")#</cfoutput>
view2.cfm:
<cfoutput>#doSomething("view 2", "http://myurl/view2")#</cfoutput>
将代码分离出来后,任何未来的变化都会变得更容易(JS 与 JS-var 分离,定义外观与调用它的各个视图分离)。例如。在添加变量时,您可以使其向后兼容,以便所有现有视图继续工作。
udf.cfm 更改:
<cfargument name="newVar" required="false" default="" />
<cfif len(arguments.newVar)>
var newVar = "#arguments.newVar#";
</cfif>
dosomething.js 更改:
// keep JS backwards compatible
if ( newVar != undefined) {
// new var was passed in, do something with it
}
// else, not passed in