HTC 编程思想
春 鱼 2004-7-19[按]
本文发表到博客园时, 使用了纯文本粘贴方法. 更改了部分格式. 可能会带来阅读上的困难.
1.摘要
本文在实例的基础上讨论了HTC(HTML Component)的编程方法,提出了一种编写脚本组件的基本模式。
2.目标读者
HTML开发人员,脚本开发人员,系统分析人员
3.背景知识
HTML, DHTML, CSS
4.引言
HTC(HTML Component)直译为HTML组件,并不是一项新技术。可是说谈不上是一门技术。实际上只是IE浏览器内置的一种脚本封装机制。由于讨论的人很少,而Microsoft也没有什么技术支持,故而应用的人很少。但是HTML有着很好的特性可以使我们的开发工作高效。并且你有可能发现,HTC或许可以改变你以往开发应用的方式。
在MSDN online对HTC的定义仅如下几句:
HTML Components (HTCs) provide a mechanism to implement components in script as Dynamic HTML (DHTML) behaviors. Saved with an .htc extension, an HTC is an HTML file that contains script and a set of HTC-specific elements that define the component.
(HTC是由HTML标记、特殊标记和脚本组成的定义了DHTML特性的组件.)
一般而言,HTC是组件化了的脚本过程。尽管引入浏览器的机制不同,但遵循相同的SDK规范。无论是脚本运行环境,还是DOM文档结构。但HTC有着极高的扩展性。也就是说,HTC可以为我们的HTML引入高级的自定义行为(behavior)。例如自定义的attribute, method, 或者事件。这就说明,我们可以使用HTC机制来开发一个有着高级特性的,可重用的,可扩展的组件。
5.实例
为了使篇幅不会太大,我们设想一个实例。话说有一天你的项目经理找到你,说客户不满意我们的项目中的用户UI设计,因为我们的客户是比较有审美情趣的人,讨厌那些windows样式的灰秃秃的按钮。所以要你设计一系列平面的,而且能随着鼠标变化颜色的按钮。你说这没问题,但是需要一天时间,不出意料地使你的项目经理惊讶之后,你解释到以你的技术水准,不可能写一堆脚本和CSS class到HTML里,你的产品一定是reusable, flexiable, 和extendable的。他答应了。于是第二天,你交给他如下源代码:
ButtonStyleFlat.htc:
另外有一个sample用于参考:
sample.html:
(分别见以下文本框)
ButtonStyleFlat.htc:
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
<script>
function DoInit(){
switch(Scheme){
case "Normal":
if(ColorOver==null) ColorOver='Orange';
if(ColorOut==null) ColorOut='RoyalBlue';
if(ColorDown==null) ColorDown='Black';
if(ColorUp==null) ColorUp='YellowGreen';
break;
default:
if(ColorOver==null) ColorOver='Orange';
if(ColorOut==null) ColorOut='RoyalBlue';
if(ColorDown==null) ColorDown='Black';
if(ColorUp==null) ColorUp='YellowGreen';
}
runtimeStyle.borderWidth='0px';
runtimeStyle.textAlign='center';
runtimeStyle.padding='3';
runtimeStyle.verticalAlign='bottom';
runtimeStyle.color='white';
runtimeStyle.cursor='hand';
runtimeStyle.background=ColorOut;
runtimeStyle.unselectable='on';
}
function DoMouseOver(){
runtimeStyle.background=ColorOver;
}
function DoMouseOut(){
runtimeStyle.background=ColorOut;
}
function DoMouseDown(){
runtimeStyle.background=ColorDown;
}
function DoMouseUp(){
runtimeStyle.background=ColorUp;
}
function DoClick(){
push.fire();
}
function showMessage(){
alert("showMessage run.");
}
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
sample.html:
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
< script >
oButton.onpush=function(){
oButton.showMessage();
}
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
![](https://i-blog.csdnimg.cn/blog_migrate/f0cd6c7f9e7ae96feae062cb48f670f0.gif)
6.分析
让我们看看所完成的工作。我们把ButtonStyleFlat.htc和sample.html放在一起。我们打开sample.html, 效果如图:
图1:实际效果图
(图像不可见)
我们发现button变平了,而且鼠标经过,移开,按下,弹起动作时颜色都会发生变化,而且仔细看脚本会发现,我们可以handle一个onpush事件和调用showMessage()方法。
这一切的变化都来自style='behavior:url(ButtonStyleFlat.htc)', 一个behavior声明。而不用在HTML中写任何脚本。我们不探讨behavior的用法,仅仅讲解如何开发一个完整的HTC。
一个完整的HTC由两个部分组成:我们把它们叫做API声明和脚本实现。API声明由以下部分组成:
a. PUBLIC:COMPONENT
这一部分组成了HTC的最外围元素。仅仅定义了所包容的内容是一个组件
b. PUBLIC:ATTACH
本部分定义了对于客户事件的处理
c. PUBLIC:PROPERTY
公开的属性定义
d. PUBLIC:EVENT
公开的事件定义
e. PUBLIC:METHOD
公开的方法定义
由于本文仅仅是一个tutorial, 仅分析使用到的语法, 更多规范可以参考MSDN文档:
ms-help://MS.MSDNQTR.2004JAN.1033/Behavior/workshop/components/htc/reference/htcref.htm
(地址可能需要修改)
或者联机版本:
http://msdn.microsoft.com/workshop/components/htc/reference/htcref.asp?frame=true
(以下规范基于IE5.0及以上版本)
PUBLIC:ATTACH
表示绑定事件与处理过程
EVENT: 表示事件句柄名
ONEVENT: 表示处理过程名
PUBLIC:PROPERTY
表示公开到环境的属性
NAME: 属性名
属性可设置类似C# property的读写器, 分别是get和put过程. 设置属性之后, 可使用HTML语法指定组件的属性值为任意值。
PUBLIC:METHOD
公开到环境的方法
NAME: 方法名
PUBLIC:EVENT
可由环境catch的事件
NAME: 事件名
ID: 内部引用名称
脚本实现
API声明仅定义了组件公开到环境的编程接口, 在组件中需要使用脚本来实现内部逻辑. 脚本实现主要有以下部分:
1. 定义事件处理过程
2. 定义PROPERTY的取设过程
3. 定义METHOD的具体实现
4. 定义EVENT的引发逻辑
5. 其他内部过程
其中EVENT的引发一般在其他过程中进行. 而脚本的语法与普通HTML页上的脚本没有什么不同.
7.实例讲解
以上的Button Style Flat虽然很短小, 但可以基本说明本文的中心内容, 即HTC编程思想. 我们接着看上面提供的实例:
a. 在第一行我们注意到, 改实例将ondocumentready事件交给了一个OnInit()的脚本过程处理(ATTACH语法). Ondocumentready是component特有的事件. 表示当表示component的前端HTML完全载入的时刻.可以说ondocumentready事件是components初始化时的过程. 在我写的所有HTC中, 都ATTACH了这个事件. 这一习惯不知道从什么时候开始的. 慢慢我发现不能离开ondocumentready了. 只要我们的HTC中需要一个类似初始化的过程, 我们就需要指定ondocumentready时刻发生的过程. 在本实例中, 我们在ondocumentready所绑定的过程中初始化了button的最初样式. 即根据schema特性决定button的外观.
b. 定义一组鼠标事件. 一般而言, 我们的component都是可见的. 而HTML页中与用户交互的主要动作是鼠标的
动作. 所以, 通常情况下, 我们总是会deal鼠标的五个基本事件mouse over, mouseout, mouse down, mouse up 和click. 同样是一个习惯, 我通常不加考虑的ATTACH 这五个事件. 即使绑定的过程是空的.
c. PROPERTY, 可以定义get和put过程做属性的取设器. 一般情况下都可以省略这两个过程. 除非要对设置的值进行合法性校验.
d. EVENT的引发. PUBLIC:EVENT声明的ID attribute用于script部分的内部引用. 当需要引发该事件时, 仅需要使用类似: push.fire()命令就可以. 环境就是开始准备catch该事件. 相当简单.
e. METHOD实现. METHOD的name attribute直接代表<script>部分的函数名. 因此可以直接声明一个同名的function. 可以有返回值, 也可以没有返回值. 在本实例中我们仅仅发出了一个客户端消息.
注意, 实例中的push事件和showMessage()方法都是没有什么实际意义的. 放在实例中仅仅为了说明编程方法.
8.总结
到这里为止, 我们可以总结一下简单模式下, 我们可以做的工作: 如何创建一个有效的HTC组件
a. ATTACH ondocumentready事件, 在过程中实现初始化时的步骤.
b. 分别ATTACH鼠标的五个基本事件. 如果该组件设计了键盘事件, 也进行同样的绑定过程.
c. 如果组件设计了特定的客户端事件, 仅需要定义并且在需要的时候引发.
d. 特定的METHOD语法也很简单. 仅需要声明一个METHOD, 并且在SCRTIPT部分实现同名函数即可.
e.考虑更复杂和实用的应用
button实在是太简单和太不值得一提了. 我们来考虑一个很受欢迎的东西: treeview. 一个所有web开发人员都非常热爱的东西.
我们知道, 现在实现treeview的方法很多. 多美观, 多实用的都有. 我们给自己提出需求, 来看一看用HTC如何设计一个好用而且节省成本的treeview.
需求
可以使用客户端数据填充其内容; 外观与windows 资源管理器一致; 可以catch到expand/collipse事件; 可以catch到节点的click事件; 可以定义节点展开/收缩的模式(记忆模式); 可以由接受环境指令expand/collipse指定的节点.
分析
如果以上需求都可以实现, 那么将是一个非常"高级"的treeview了. 我们逐一分析上述需求:
1. 使用客户端数据填充: 既然是treeview, 则必然由节点构成. 既然是节点, 就必然体现一定的数据. 而数据的由来一般情况下是由后端传送来的. 这就要求我们最好使用一种数据格式. 不需要更改, 在后端和前端都可读. 一般朋友都会想到用XML. 这是很好的想法. 这样, 我们的treeview必须能够按照一定的规则读取XML数据. 将节点解析出来, 并且使用一定的输出方法输出目标HTML形成带有图标, 文本, 节点线的外观. 这样过程一般在OnInit()过程中进行.
2. expand/collipse事件. 有时候环境需要了解treeview的状态. 例如展开某个节点是自动显示某些内容. 因此环境必须随时了解treeview里发生了什么. 这样需要我们分别定义expand/collispse事件. 在某些情况下自动地引发他们.
3. 节点的click事件很重要. 一般情况下, 用户单击某节点是总是会期望得到什么.
4. 设定展开/收缩的模式. 我们可以指定treeview是否自己记住展开的节点的状态. 而有些情况下我们希望treeview不会太长而希望不准同时展开两个节点. 这需要我们定义一个PROPERTY. 可以通过HTML attribute或者script设定该值从而影响compenent的behavior.
5. 接受环境指定改变节点状态. 如果我们希望不经过用户操作而自动打开某节点(不经过页发回), 希望通过环境的script命令操作treeview. 我们可以定义一些列METHOD, 例如expandNode(id): 展开指定id值的节点.
这样, 我们就开发了一个有着高级特性的treeview component. 而且该组件的重用性是很高的. 我们只需要在HTML中插入一个特定的标记, 类似<Timeline:Treeview ><xml data…. /></Timeline:Treeview>. 你的 HTML页就会出现一个非常漂亮的树型目录了.
结束
本文论述了开发HTC的一般性方法. 作者希望可以通过本文, 使广大web工作者认识到HTC的优势. 以期待可以抛砖引玉, 得到遍地开花的美好结果.
另
作者发现经常有朋友转载文章而不说明出处. 作者欢迎转载, 但同时希望得到应有的尊重.
本文最初发于博客园( http://www.cnblogs.com)之春鱼文集(Jay's Blog)( http://www.cnblogs.com/jayxu).
结束编辑于 2004-8-5. 将进行不定期修改.
修改历史:
posted on 2004-08-05 00:22 春鱼 阅读(8022) 评论(39) 编辑 收藏 所属分类: 脚本技术(DHTML)
评论
我们在曾使用了大量的HTC。HTC有很好的思想,但由于其基于IE,不稳定。代码复杂之后,会出现很多莫名其妙的BUG。
例如,MS IE WebControls中的TreeView,如果每个节点都带一个小图标,节点有上百个或者数百个,此时,就有可能出现莫名其妙的问题。我们为此事询问Microsoft,得到的答复是,HTC中的图片太多,导致过多图片请求,需要修改IE在注册表中的配置解决。Microsoft并且认为不是BUG,而认为只是一个需求缺陷。
我们的经验是,不建议基于Web开发过于复杂的UI界面。因为IE这个开发环境不够可靠,而且微软也不打算改进它。 回复 引用 查看
#2楼 2004-08-05 08:55 春鱼
我前面讲过. HTC仅仅是一种封装机制. 并不是新技术. 所以不会出现IE运行不稳定的状况. 如果出现了不稳定, 大部分原因我想应该是代码不够健壮所致.
MS IE WebControls本来就是一套样本类型的组件. Microsoft在MSDN中已经申明目前并没有任何技术支持可用. 并且其源代码是开放的. 自然可以找到问题所在.
脚本环境与IE的版本有很大关系. web是可以承受复杂的UI的. 如果你发现IE的脚本环境不够可靠, 那应该不是IE的问题. Microsoft在这一方面做的工作比任何 其他浏览器都多. 回复 引用 查看
#3楼 2004-08-05 10:09 宝玉
如果xml+xsl+htc结合,可以做出很棒的真正换皮肤换风格的控件。目前正实验阶段。 回复 引用 查看
#4楼 2004-08-05 10:13 spidertan
很好,我也一直在用htc作bs程序(bug跟踪),我主要还是用在处理数据、与数据库打交道上,希望交流 回复 引用 查看
#5楼 2004-08-05 11:20 杨若
HTC基于脚本语言完成的针对文档对象模型和Web表现层的可重用对象结合IE内置的MSXML帮助我完成了很多在ASP中显得很高难度的动作。不过自从ASP.NET逐渐强大以及带宽逐渐不再是主要问题以后,HTC的价值没有以前那么大了。同时微软对HTC的支持好像也不如以前了。所以我对HTC的前景并不十分看好。 回复 引用 查看
#6楼 2004-08-05 11:37 春鱼
HTC的技术很简单. 没有什么支持不支持的分别. 也没有"前景"的概念. 并且HTC仅仅是客户端的技术. 和ASP/ASP.NET, 带宽等等都没有任何牵强的联系.
另外, HTC并不能直接处理数据, 和数据库打交道.
HTC的基础DHTML. 而按照我的理解, DHTML包含HTML, Scripting技术和IE DOM对象. 他们都是基于IE的客户端技术. 回复 引用 查看
#7楼 2004-08-05 11:50 myrat
htc在现在是个好东西,但是我也不看好它的未来,起码ms没有怎么宣传它,支持它 回复 引用 查看
#8楼 2004-08-05 11:57 myrat
才看到春鱼的评论,我觉得它没有什么前景的意思是
1。它不太可能被改进了,
2。它不会成为主流,只会慢慢被淘汰 回复 引用 查看
#9楼 2004-08-05 12:20 宝玉
HTC对于控件的封装很多地方比纯js有优势,例如它可以有自己的属性、方法、事件,在asp.net中的web控件的客户端脚本,htc是首选(IE浏览器) 回复 引用 查看
#10楼 2004-08-05 13:51 Xpc
不管Asp或Asp.net多么"强大",它终究是一种服务器端技术。Asp.net的出现并没有给IE客户端带来更多的东西。而对于客户端技术,MS没有改进它也许是在现有体系下无法更动了。
但是不可否认,过多的客户端技术对程序的兼容性及稳定性会有很大的影响(除了Bug之外),要寻求强大的客户端功能也违背了B/S架构的初衷。 回复 引用 查看
#11楼 2004-08-05 14:47 春鱼
B/S结构不是生来的"瘦". 如果可以变得灵活和强大, 为什么一定要坚持贫穷的立场?
HTC的确会带来兼容性的问题. 但任何事情也不是绝对的. HTC不是一场革命, 不是包治百病的万能药. 这不是大是大非的问题. 而是一个度的问题.
正因为脚本语言简单易用, 才会出现所谓"不稳定性". 回复 引用 查看
#12楼 2004-08-05 23:17 温少
@春鱼
我想你缺乏使用HTC开发过复杂的界面程序的经验。(如果说错了,或者不恰当,请别介意)。
我曾经在大约2001年时,编写过Web应用程序,基于ASP .NET,使用了HTC。最初是Kingdee的HR系统,后来是EAS .NET。
在EAS .NET中,大量采用了HTC,包括菜单、报表、打印。其中复杂的报表HTC组件,大约7万行,功能强大,支持虚模式、分组、公式等,可是说十分的强大,要比曾经轰动一时的方城Web报表还要强。KINGDEE EAS .NET是我见过最强大和花哨的Web应用。
(澄清一下,在EAS .NET中,这些使用了HTC的WebControl,我没参与开发。那时候我专注于开发工作流。)
EAS .NET的WebControl,界面非常漂亮,都是支持更换Skin的,我们的人机工程部,为这些控件设计了不同的Skin,修改了Skin之后,就如同Winamp中更换Skin、Windows更换桌面主题一样,完全不同的色调风格。
强大花哨的界面,一个后果就是复杂。这些WebControl中,使用了大量的小图片,HTC组件中动态构建的界面中,装载图片的方式和普通的Web是不同的。我们的程序出现了一种症状:当我们操作界面时,IE会偶然锁定,锁定后,你在IE上作任何操作都是无效的,包括关闭窗口的操作,你只能从TaskManager中把它杀掉。这种死锁不是每次都发生,他是偶然发生的。
也许你会认为我们不熟悉HTC,或者程序没写好,但我不是这样认为的。Microsoft提供的IE WebControl同样存在我所说的上述问题,其中Tab Control和TreeView都是不稳定的,特别是Tab Control。
在开发HTC的过程中,遇到问题时,我们是有咨询过微软,具体的结果我在前面的评论中已经说过,就不再重复。
我们在Microsoft技术支持人员得到的信息是,IE开发组的人员,每年都在减少。其实就是暗示着我们,不要太依赖IE。
再重复一下我的观点:
不建议基于Web开发过于复杂的UI界面,因为IE这个开发环境不够可靠,而且微软也不打算改进它。 回复 引用 查看
#13楼 2004-08-06 00:49 春鱼
任何技术都有可为, 有所不为. 我已经一再强调HTC仅仅是脚本的封装, 没有任何新鲜的东西, 也并没有声称HTC改变了客户端UI开发的局面. 本文的目的仅仅在于总结或者推荐一下HTC的技术特点. 仅仅是入门的材料而已. 从头到位都没有流露出HTC强大之类的情绪.也不推荐使用HTC开发"过于复杂的UI".
至于所谓IE的开发环境. 并非我执迷不悟. 乃是我实在想象不出来有什么地方"不可靠". 实际上IE6.0以上已经非常成熟. 我们能做的, 仅仅是在脚本可以正常运行的前提下开发我们的需求. 所谓适可而止, 如果你的应用超出了IE的能力, 那么你的小组应该考虑换用其他解决方案了.
这样辩论实在没意思. 就算有意思, 也没必要批判IE, 我们只有一个IE, 不管是好是坏, 我们都没有其他选择. 更没必要提到Microsoft. Microsoft不止是一个IE, Microsoft想的事情很多. 我们和Microsoft之间, 其实谈不上什么关系. 回复 引用 查看
#14楼 2004-08-06 03:01 温少
@春鱼
可能产生误会了:)
其实我想说,如果要作复杂的Client端UI,还是选择Windows Form之类的Rich Client。
我,还有一些曾编写过大量HTC的朋友,吃过亏之后,都觉得IE不是一个好的开发平台。这段时间网上出现很多复杂的基于HTC的Web UI界面,其实博客园的编辑器也算是一个。IE并不差,这种复杂度还是可以承受的,但是更进一步呢?可能就不行了。
因此,对于企业来说,把原来基于Windows应用程序的客户端,全部迁移到Web上来,最终会发现一些问题,而且很难解决。这可是我们亲身经历,我们痛过,所以感觉深刻,也希望告诫后来者,作为前车之鉴。 回复 引用 查看
#15楼 2004-08-06 09:28 春鱼
如果blog早几年流行起来, 也许本文三年前就应该写成了. 我只是想把自己的经验, 见解记录下来, 并没有非和谁一争高下.
技术没有绝对的是非曲直, 技术本身没有任何值得炫耀的地方, 对于做应用的开发人员来说.
HTC本来就是可有可无的东西. 其影响力还达不到对解决方案的选择. 再者, HTC也并不能代表"瘦客户端UI". 仅仅是一种替代的选择. 没有必要我们因为知道HTC, 就一定要用HTC.
上升到胖瘦的选择问题, 如果不是单纯为了取悦用户, 或者炫耀技术之外, 根本没有必要, 也不可能把Windows的UI完全模拟出来, 这是开发成本的问题, 是效率的问题, 是风险的问题. 事实上, 使用基本的 HTML form element 已经可以满足需要. 也是最朴素的解决方法. 没有一种解决方案是万能的. 仅仅是优势的权衡. 回复 引用 查看
#16楼 2004-08-06 17:52 杨若
@春鱼
你误会了我对HTC的理解程度。
一:我们使用复杂的客户端技术处理一些逻辑,一定程度上就是为了降低网络访问频率。当带宽不是问题的时候,复杂逻辑由服务端处理其实从整体上来看是比较合理的(安全性,可扩展性等)。因为毕竟IE的Script runtime能力很有限。
二:ASP和ASP.NET在我看来主要区别中的一点就是:
ASP基于HTTP的扩展与封装做的很弱,他存在的价值就是COM的黏合剂。在MS平台下使用ASP+COM/COM+完成灵活、交互复杂的系统还是很吃力的事情,当你的客户端请求不想只局限于FORM的get,post的时候,借助HTC+Microsoft.XMLDOM/XMLHTTP就可以实现一些相对传统ASP技术实现起来比较困难的功能,比如Ht