首先我们先来了解一下ASP页面执行的流程
1.IIS找到ASP文件,提交给ASP引擎(一般是ASP.DLL)处理。
2.引擎打开这个ASP文件,找出<%和%>之间的内容,当然还有<script runAt="server">和对应的</script>之间的内容,这些内容称为脚本块。只有脚本块里的内容被引擎解析,其他内容不管,作为没有意义的字符插在脚本块之间。有必要说明一下的是,其实被解析的内容还不止这些,<!--#include ***-->类的服务器端包含文件也是由引擎包含进来并加以处理的。如果你读的程序比较多,你还会知道有的runAt属性标注为"Server"的<object>对象也是会被处理的,这里不做深入讨论。
3.引擎执行脚本块中的脚本,这些服务器端的脚本是作为一个整体被执行的,也就是说,可以写出如下的代码:
<% Dim i For i=1 to 5 %> Hello IT.HXW.RED! <% Next %>
引擎并不会将这些脚本块分开解析,而使两个脚本块都发生语法错误。所以我们得到如下结论:并非所有非服务器脚本的代码都会被发送到客户端,有可能这段非服务器脚本的代码被脚本块限制了。服务器是一定不会操心客户端脚本的执行问题的,但是可以通过服务器端的脚本输出不同的客户端脚本。
4.最终引擎产生了一个文本流,或者说是脚本的执行结果,可以认为这是一个字符串,就是发送到客户端浏览器的网页的代码。客户端浏览器将页面显示出来,此时页面的源代码(源文件)是不包含服务器端的脚本的,但包含了服务器端脚本的执行结果(这是显然的)。
<% … %> 与 <script runat="server">…</script>
它们都是服务器端的脚本,同时被处理执行。他们执行时是作为一个整体的。
<% … %> 与 <script language="…">…</script>
前者是服务器端脚本,后者是客户端脚本。前者先执行,后者后执行。
其实也不尽然,二者的脚本是有可能在同时被执行的,但空间不同,仍然是:前者在服务器上执行,后者在客户端浏览器里执行。前者在逻辑上一定提前于后者执行。同时我们也得到结论:在同一个页面的执行中,客户端脚本无论如何不能反馈给服务器端脚本,也就是说,客户端浏览你的留言本并且提交新留言或者是任何客户端脚本获取的值都不可能在同一次服务器响应中被处理。
关于组件的调用
注意服务器端脚本和客户端脚本都是脚本,自然都可以创建xmlhttp组件、ADODB.Connection组件等,但是并不是放在哪里都可以的。
xmlhttp如果用于服务器的抓取网页(比如采集)就要在服务器脚本里创建了,而如果是用于客户端的ajax无刷新而后台访问服务器端的页面,那么就是运行于客户端的了,自然在客户端创建。
ADODB.Connection组件用于访问数据库,一般来说在服务器端创建,毕竟是服务器端的asp程序在跑数据库的数据,但如果你的数据库真的是在客户端连接的,那么就毫无疑问在客户端脚本里创建了。
总之,矛盾着的事物及其每一个侧面各有其特点。不同事物有不同的矛盾;同一事物在发展的不同过程和不同阶段上有不同的矛盾;同一事物中的不同矛盾、同一矛盾的两个不同方面各有其特殊性(看不懂的可以略去不看……)。这一原理要求我们坚持具体问题具体分析原则,在矛盾普遍性原理的指导下,具体分析矛盾的特殊性,并找出解决矛盾的正确方法。反对千篇一律地采用一种方法解决不同事物的矛盾。“一把钥匙开一把锁,到什么山唱什么歌”讲的就是这个道理。
服务器端VBScript脚本创建对象使用Server.CreateObject(className)方法,客户端VBScript脚本创建对象使用CreateObject(className)方法。
典型错误
<% Function TSize(b) ’这是我自定义的函数 TSize="好学IT学院" end function %> <a href="javascript:<%TSize(’变量’)%>" >点这里要使用我定义的函数</a>
错误分析:
混淆了服务器端脚本和客户端脚本的区别。实际执行时我们会发现,客户端根本没有收到什么TSize之类的代码,因为TSize是服务器端的程序,被引擎处理之后(注意引擎对于函数的处理,纯粹是给服务器端脚本调用的,不会发回到客户端)就消失了,不可能在客户端起作用。这就是说,客户端脚本无法直接调用服务器端脚本的函数。
事实上,这个程序是有语法错误的,引擎处理这段内容的时候先找到了<%和%>之间的内容,也就是<%TSize(’变量’)%>,显然这段内容不符合VBScript的语法规则。嗯,改成<%=TSize("变量")%>在服务器端脚本就没有语法错误了,这时TSize函数可以正常返回值"中国",于是客户端收到的href属性是这样写的:"javascript:中国",是无法执行的。