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. 将进行不定期修改.

我们在曾使用了大量的HTC。HTC有很好的思想，但由于其基于IE，不稳定。代码复杂之后，会出现很多莫名其妙的BUG。

例如，MS IE WebControls中的TreeView，如果每个节点都带一个小图标，节点有上百个或者数百个，此时，就有可能出现莫名其妙的问题。我们为此事询问 Microsoft，得到的答复是，HTC中的图片太多，导致过多图片请求，需要修改IE在注册表中的配置解决。Microsoft并且认为不是BUG，而认为只是一个需求缺陷。

我们的经验是，不建议基于Web开发过于复杂的UI界面。因为IE这个开发环境不够可靠，而且微软也不打算改进它。

我前面讲过. HTC仅仅是一种封装机制. 并不是新技术. 所以不会出现IE运行不稳定的状况. 如果出现了不稳定, 大部分原因我想应该是代码不够健壮所致.

MS IE WebControls本来就是一套样本类型的组件. Microsoft在MSDN中已经申明目前并没有任何技术支持可用. 并且其源代码是开放的. 自然可以找到问题所在.

脚本环境与IE的版本有很大关系. web是可以承受复杂的UI的. 如果你发现IE的脚本环境不够可靠, 那应该不是IE的问题. Microsoft在这一方面做的工作比任何 其他浏览器都多.

如果xml+xsl+htc结合，可以做出很棒的真正换皮肤换风格的控件。目前正实验阶段。

HTC基于脚本语言完成的针对文档对象模型和Web表现层的可重用对象结合IE内置的MSXML帮助我完成了很多在ASP中显得很高难度的动作。不过自从ASP.NET逐渐强大以及带宽逐渐不再是主要问题以后，HTC的价值没有以前那么大了。同时微软对HTC的支持好像也不如以前了。所以我对HTC 的前景并不十分看好。

我想你缺乏使用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这个开发环境不够可靠，而且微软也不打算改进它。

任何技术都有可为, 有所不为. 我已经一再强调HTC仅仅是脚本的封装, 没有任何新鲜的东西, 也并没有声称HTC改变了客户端UI开发的局面. 本文的目的仅仅在于总结或者推荐一下HTC的技术特点. 仅仅是入门的材料而已. 从头到位都没有流露出HTC强大之类的情绪.也不推荐使用HTC开发"过于复杂的UI".

至于所谓IE的开发环境. 并非我执迷不悟. 乃是我实在想象不出来有什么地方"不可靠". 实际上IE6.0以上已经非常成熟. 我们能做的, 仅仅是在脚本可以正常运行的前提下开发我们的需求. 所谓适可而止, 如果你的应用超出了IE的能力, 那么你的小组应该考虑换用其他解决方案了.

这样辩论实在没意思. 就算有意思, 也没必要批判IE, 我们只有一个IE, 不管是好是坏, 我们都没有其他选择. 更没必要提到Microsoft. Microsoft不止是一个IE, Microsoft想的事情很多. 我们和Microsoft之间, 其实谈不上什么关系.

其实我想说，如果要作复杂的Client端UI，还是选择Windows Form之类的Rich Client。

我，还有一些曾编写过大量HTC的朋友，吃过亏之后，都觉得IE不是一个好的开发平台。这段时间网上出现很多复杂的基于HTC的Web UI界面，其实博客园的编辑器也算是一个。IE并不差，这种复杂度还是可以承受的，但是更进一步呢？可能就不行了。

因此，对于企业来说，把原来基于Windows应用程序的客户端，全部迁移到Web上来，最终会发现一些问题，而且很难解决。这可是我们亲身经历，我们痛过，所以感觉深刻，也希望告诫后来者，作为前车之鉴。

如果blog早几年流行起来, 也许本文三年前就应该写成了. 我只是想把自己的经验, 见解记录下来, 并没有非和谁一争高下.

技术没有绝对的是非曲直, 技术本身没有任何值得炫耀的地方, 对于做应用的开发人员来说.

HTC本来就是可有可无的东西. 其影响力还达不到对解决方案的选择. 再者, HTC也并不能代表"瘦客户端UI". 仅仅是一种替代的选择. 没有必要我们因为知道HTC, 就一定要用HTC.

上升到胖瘦的选择问题, 如果不是单纯为了取悦用户, 或者炫耀技术之外, 根本没有必要, 也不可能把Windows的UI完全模拟出来, 这是开发成本的问题, 是效率的问题, 是风险的问题. 事实上, 使用基本的 HTML form element 已经可以满足需要. 也是最朴素的解决方法. 没有一种解决方案是万能的. 仅仅是优势的权衡.

你误会了我对HTC的理解程度。
一：我们使用复杂的客户端技术处理一些逻辑，一定程度上就是为了降低网络访问频率。当带宽不是问题的时候，复杂逻辑由服务端处理其实从整体上来看是比较合理的（安全性，可扩展性等）。因为毕竟IE的Script runtime能力很有限。
二：ASP和ASP.NET在我看来主要区别中的一点就是：
      ASP基于HTTP的扩展与封装做的很弱，他存在的价值就是COM的黏合剂。在MS平台下使用ASP+COM/COM+完成灵活、交互复杂的系统还是很吃力的事情，当你的客户端请求不想只局限于FORM的get,post的时候，借助HTC+Microsoft.XMLDOM/XMLHTTP 就可以实现一些相对传统ASP技术实现起来比较困难的功能，比如Http异步请求，页面的局部刷新等等。所以HTC+ Microsoft.XMLDOM/XMLHTTP对我来说的确在很大程度上弥补了ASP的不足。
     ASP.NET将http过程做了很不错的封装，ViewState帮助我们完成信息从服务端到客户端的交互（不过也有若干缺陷），我们几乎不需要在客户端考虑Post的问题了。所以当ASP.NET使Client和Server之间的界限变得不是那么硬的时候。Client的处理能力仿佛加强了。
     所以随着ASP.NET出现，我没有再像以前那样把基于IE浏览器的客户端技术看得过重。

HTC标准由微软提出，运行在IE特定环境之下，微软的支持与否对HTC的健康发展至关重要。你能说msdn不是你了解学习htc的地方吗？

我的看法和温少比较接近。HTC是一个不错的基于IE的组建模型技术，思想也很不错。但是如果尝试使用HTC去构建基于IE的Rich Client体系的话，存在着一定的风险。HTC做一些相对轻型的可重用组件还是不错的。所以我们讨论的只是HTC定位的问题，而非此种技术的好坏。
另：我从来没有使用HTC访问数据库，也从来没有在IE端直接访问数据库的经验和经历。我只是利用HTC封装的组件处理Microsoft.XMLDOM 从服务端Load的XmlStream，利用数据绑定做显示，再通过Microsfot.XMLHTTP提交到服务端来完成最常见的数据CIUD工作。

我感觉随着微软下一代操作系统Longhorn对Internet支持的逐渐强大，Avalon做为新一代界面框架将成使资源展现，搜索时所处的位置是本机还是网络有所弱化。我没见过Longhorn是什么样子，但我感觉到时候我们访问internel上的资源，不管html，图像，媒体。可以通过更多途径。IE+DHtml的展现方式不会被取代，但更强大的Xaml将成为Microsoft的主要方向。微软对DHTML整个体系的支持都在减弱。