技术在进步, 世界在变得美好...
posted on 2004-08-05 00:22 春鱼 阅读(8375) 评论(39) 编辑 收藏 网摘 所属分类: 脚本技术(DHTML)
我们在曾使用了大量的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作bs程序（bug跟踪），我主要还是用在处理数据、与数据库打交道上，希望交流 回复 引用
HTC基于脚本语言完成的针对文档对象模型和Web表现层的可重用对象结合IE内置的MSXML帮助我完成了很多在ASP中显得很高难度的动作。不过自从ASP.NET逐渐强大以及带宽逐渐不再是主要问题以后，HTC的价值没有以前那么大了。同时微软对HTC的支持好像也不如以前了。所以我对HTC的前景并不十分看好。 回复 引用 查看
HTC的技术很简单. 没有什么支持不支持的分别. 也没有"前景"的概念. 并且HTC仅仅是客户端的技术. 和ASP/ASP.NET, 带宽等等都没有任何牵强的联系. 另外, HTC并不能直接处理数据, 和数据库打交道. HTC的基础DHTML. 而按照我的理解, DHTML包含HTML, Scripting技术和IE DOM对象. 他们都是基于IE的客户端技术. 回复 引用 查看
htc在现在是个好东西，但是我也不看好它的未来，起码ms没有怎么宣传它，支持它 回复 引用
才看到春鱼的评论，我觉得它没有什么前景的意思是 1。它不太可能被改进了， 2。它不会成为主流，只会慢慢被淘汰 回复 引用
HTC对于控件的封装很多地方比纯js有优势，例如它可以有自己的属性、方法、事件，在asp.net中的web控件的客户端脚本，htc是首选（IE浏览器） 回复 引用
不管Asp或Asp.net多么"强大",它终究是一种服务器端技术。Asp.net的出现并没有给IE客户端带来更多的东西。而对于客户端技术，MS没有改进它也许是在现有体系下无法更动了。 但是不可否认，过多的客户端技术对程序的兼容性及稳定性会有很大的影响(除了Bug之外),要寻求强大的客户端功能也违背了B/S架构的初衷。 回复 引用
B/S结构不是生来的"瘦". 如果可以变得灵活和强大, 为什么一定要坚持贫穷的立场? 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整个体系的支持都在减弱。 回复 引用
同意 温少 的：不建议基于Web开发过于复杂的UI界面！我也曾使用HTC技术开发过一套投票系统，但是在数据条目过万的情况下，在客户的反映速度也慢了，而且也经常出现莫名其妙的错误！ 不过，即使是这样，我做东西时还是喜欢用HTC封装！ 回复 引用 查看
偶然在搜索資料的時候看到這篇文章 這里的人——很強 我只是綱管，不懂js，了解一些C++ 今天安裝 ISA 2004 Standard 後 遇到控制台問題ox80070057 Parameters Incorrect. 控制台樹無法展開和進一步配置 我對它的界面結構不了解 起初懷疑Java支持問題 加裝了JRE，老樣子 後來大致看了一下，頁面涉及到一個HTC文檔 才上網查查 我的IE6sp1應是沒問題的 不知是不是使用了HTC的結構有兼容性問題 還有，對ox80070057的搜索結果寥寥，幾乎沒有匹配的 一般在支持比較少的技術上才會這樣，可能是HTC的問題 不懂的是，即然MS不推荐，為何要在新產品上弄個這樣的 讓人剛安裝就卡殼 不知是否代表對HTC技術有進一步的意向 回复 引用
不错，正是我需要的内容！谢谢！ 顺便说一下， 物尽其用 比如我们用PS设计图片，DW设计网页，VC设计程序，你非要叫VC设计图片，DW设计程序，PS设计网页。怎么行？ 语言也一样，该是它干的就让它干，它干不了的千万不要叫它干！ 回复 引用
HTC..开发CRM时把我给搞惨了...很多情况下都会出错了...而且是时出时不出..在全文没读完整的情况下也会出错..:(~...以上都厉害...分析得那么深...我只知道不好我就把它废掉了... 回复 引用
在全文没读完整的情况下也会出错..:(~... 你没有判断读完否？ 函数执行前需要判断一下element.readState 比如 function loadData() { var docLen = parseInt(window.document.all.length) if (!documentComplete) for (var i=0;i<docLen;i++) { if ( window.document.all[i].readyState != 'complete') { if ((new Date() - startTime) < 500) { setTimeout('window.document.all.' + element.id + '.loadData()',10) return } } } documentComplete = true ... } 回复 引用
同感，楼上的弟兄们都很强。 确实，之所以选择B/S结构，就是想要减少对客户端的依赖，扩展性也更强。 IE平台的确不十分稳定，因为这主要取决于客户机，我们的服务器是经过专业人员维护的，客户的操作系统的稳定性无法跟我们的服务器相比。在中国，现在依然还有人在使用 Windows 98，绝大部分的机器内存容量在 256M 左右，客户的操作能力也各有高低，这些都直接影响着我们的东西能否运行的良好。 面对层次不同的客户，我们对于提供给他们的接口，应该尽可能的选择耦合度最小的，依赖程度最低的元素。 就像现在的ATM，提供给客户的只有一个触摸式显示屏。 回复 引用
HTC说白了是一种封装技术～不是什么其它技术的另类选择～楼主只是想大家了解一种可重用的技术～不过说实在的～微软已经渐渐放弃甚至屏蔽了对HTC的支持。等你们的客户不断向你投诉的时候～你就很想狠狠地骂微软了～ 回复 引用
有时候真舍不得脚本和DHTML 回复 引用 查看
用纯JS模拟方法，实践完全可以，for example: void function XClass() { this.objXML = null; // Property this.GetXML = XClass_GetXML; // Method for get this.SetXML = XClass_SetXML; // set this.OnCreate = null; // Event, Pointer for XClass // For user's define. this.OnChange = null; this.Create = XClass_Create; // Constructor for XClass } function XClass_GetXML() { return ( this.objXML ); } function XClass_SetXML( objXMLDoc ) { this.objXML = objXMLDoc; this.OnChange(); // Fire OnChange event if the function is executed. if the pointer to OnChange is set to null, it will do nothing. } function XClass_Create() { this.OnCreate(); // Fire event when constructing // If the pointer to event is set to null // it will do nothing. // Do something you want; // Databinding for html instance objHTML.objXML = this.objXML; objHTML.GetXML = this.GetXML; objHTML.SetXML = this.SetXML; objHTML.OnChange = this.OnChange; // return ( /* html instance */ ); } // Construct an instance of class var objXClass = new XClass(); objXClass.objXML = objXMLDoc; // Code omitted, won't fire the OnChange event. objXClass.SetXML( objXMLDoc ) // OnChange event will be fired. objXClass.GetXML(); // it will return the value iof previous line objXClass = objXClass.Create(); // Get html instance after databinding, and OnCreate event firing. // you can do what it has been done, except Create() method, because of which didn't bind to the html instance, 回复 引用
不要期待服务端能做很多事，因为这不符合逻辑，人云亦云，你什么都干不成功． 回复 引用
To discuss the first posting contact me:QQ:517527634 Who please notes what you want to discuss with me with your posting which makes a frend with me. thanks a lot. I am 6qing88 回复 引用
是的。春鱼只是想大家了解一种可重用的技术，并不是一味的推崇。春鱼支持你，希望能频频发表一些新技术。。。。。。。。。。 回复 引用
偶发现在HTC中使用setTimeout("functionName()",100)这类系统函数,如果functionName()是定义在HTC中,会报对象不存在?? functionName()定义在调用htc的页面中. 真TMD垃圾; 回复 引用
接上:在使用setTimeout("functionName()",100)这类函数时,必须写成setTimeout(functionName,100),也就是说,只能通过句柄来访问. TMD!! 回复 引用
小弟也是最近在看HTC方面的资料，写了一段大家看看 http://www.microsystem.cn/data/htc/datacheck.htm 回复 引用
如何使2个htc对同一个对象同时起作用？ 声明没有同名事件 回复 引用
呵呵，HTC 好像并不与 ASP.NET 冲突吧。 如果我们封装一个 ASP.NET Web Control，我一定会把输出的大量 HTML 和 JS 封装到 HTC 里。 毕竟，ASP.NET 在服务器端生成的（Render）还是 HTML，还是要到客户端去执行——这恰恰是 HTC 的舞台。 至于 HTC 是否适于 RIA，那倒未必。诚然，HTC 效率上未必很好，可有多少应用是真正很 Rich 的？ 再说，楼上各位用 HTC 多的朋友，想必都是用来做企业 MIS 吧，所以才那么不在乎带宽，那么耍弄花巧。 如果说往一个 DataGrid HTC 中加载大量的数据会导致这样那样的问题，那为何不动态加载呢？ AJAX 出来前好多年，就可以通过 IFrame 甚至 Frame 实现“异步加载”，何况2000年后可以用XMLHTTP，IE5以后可以用 IE:Download... 这些都不是技术本身的问题：好比有朋友说的，你总不会拿 VC 来做平面设计吧。 只是 RIA 方面，我更看好 Flash，只可惜那些学 Flash 的哥们过于在意“故事情节”而懂一些AS的人中，目前能够有很好的编码技巧的又很少。 2003年，曾经封装过一套基于 Flash 的客户端 Chart 组件，配合 ASP/ASP.NET/JSP 等等动态网页技术，这其实是一条很好的 RIA 路线，可惜后来那几个哥们都去拼“全国十大金闪”去了——有两个杀入十强，却又怎么样呢？只是美工强一些罢了，遗憾遗憾 无论 HTC 的明天如何，但 HTC 这样的 Object Based 的应用方式对于解决B/S应用中客户端方面的代码的维护问题有很大的好处，我喜欢。 至于有朋友说到IE“假死”或者HTC没载入完全就报错的问题，我想是编程的品质还有待提高——例如对 HTC/CSS 的基础知识掌握得还不够扎实。 2000年我们就在WebChat中通过HTC设计了在一个IE窗口中用Tab登入多个聊天室聊天的系统（采用Applet和服务器交换数据，采用刷新式命中率太低，服务器负载浪费太大），万人在线对于服务器也没多大影响，而对于客户端而言也没见的有多慢（当然不能同时进入太多聊天频道）。 回复 引用
我喜欢htc,那些不想用的,可能你们用得太多了,技术已经很强了..... 回复 引用
htc欲哭无泪，欲罢不能呀 回复 引用
支持支持! 回复 引用
推荐一个免费的多语种在线翻译网站 http://www.165net.com ，可进行十多种语言的互译 回复 引用
HTC 使用中的很多问题其实是对 dhtml/dom/js/css 等基本技术掌握不扎实造成的，但是 HTC 技术本身确实也有问题，比如： 1、当一个页面中有太多元素挂接htc时，后面的元素有时会挂不上htc 2、一个页面会对同一个htc产生不止一次的http get 请求，具体重复次数没有规律 3、htc 的加载在 ie6 和主文档解析是并行的，在ie7 下，是串行的并且在主文档分析完之后才执行其中的代码 回复 引用
Powered by: 博客园 Copyright © 春鱼