如果没有<%xxxx%>，后台的数据与页面的界面对象的对应靠的是界面对象的name/id？
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
后台数据与页面对象的对应有很多方式，一般用xml island binging，但只要参照这个，
自己也可以用htc,js之类搞出其他自己想要的绑定方式，我就是自己做的，因为标准绑定
有规定的格式，要加个连接或者图片之类的效果都要事先转换xml文档，而这些其实应该是
界面而不是数据，所以做了一些htc，可以定义显示模板，数据的xml就是数据，没有任何显示元素
除非中间件返回的xml数据本身需要调整才需要转换

页面中有没有<%xxxx%>其实并不要紧，一般如果用asp做，<%%>肯定还是要的，因为一般系统都要
处理用户，在线信息之类的。

用绑定之后，页面可以马上出现静态内容，具体数据后续出现，不需要页面内容全部在服务端转换
后才传回，而且开发阶段可以先弄几个典型的静态xml文件测试效果，甚至都还不需要中间件和数据库
的存在，这在做给客户看的原型系统时有用。还有就是系统中的asp文件会很规则，除了一写显示用的
页面外，其他大都是数据asp,类似xxx.xml.asp之类的，这些asp仍然可被其他比如客户端应用程序使用。


做一个通用的"com+"，本来是好像比较困难，但现在我实现之后回头想想，我的大部分时间其实都花在
技术准备上，也就是学习xml,xsl,xpath之类，主要我觉得是想法问题，只要想到了，实现起来一点都
不困难，我从把这想明白，到写出Command组件，也就只花了大概两天时间，到现在为止，系统的绝大部分
功能都出来了，中间件都没怎么改动，只是改了一下Schema等文档的缓存方式，改成可配置缓不缓存，
以利于调试，而Command组件也就两个主要方法，500来行代码。
组件以外的就是增加Schema的内容而已，Schema的内容都是很规则的，只要做的人明白业务需求，
明白表结构以及表之间的关系，就没问题。
完全是一个非高级程序员可以进行的，说实话，现在我一直是在做工作流，工作流以外的功能我都
已经不参与了，都由一个同事在管Schema，他只是一个网页开发人员，只知道ASP,HTML,XML，表结构和
存储过程由另外一个同事管，根本不再需要什么会VC,Delphi之类的人员参与。
如果不考虑时间因素，他们两个人绝对搞定一切，至于截然不同的系统，当然是需要是大致一个类型
的系统，我说了比较适合信息类系统，要搞定一个比如银行业务系统的话，现在是绝不可能的
我绝不会想着要一个架构搞定世界上所有系统，那样的话我绝对是不只叫狂妄了，不过
现在的信息系统还是很多的，是吧

ie庞大好，我还希望他更庞大些(有些功能我还是不满意的)反正系统安装后就有了。
我觉得很多人在那里争论ie，ms之类的可能是得不偿失，有那时间不如去搞别的。