输入的交互设计，与select标签的不同，与autocomplete不同，
每个web组件有不同的交互效果，原生的input type="text"就是输入框了，想输入就输入什么，也能上传二进制数据（photo，audio，video）。
为了方便你输入，出现autocomplete。
也有纯鼠标点点，也为了防止你输入范围外的数据，出现了<select>选择标签。
comboBox，则是select和autocomplete的结合，你只能输入指定范围的数据，不想输入，也能鼠标点点。
类似的有DatePicker，也就是日期组件了。
上面都是小数据输入了，可能就是一句话。
大数据输入，原生的就是textarea，组件有各种Editor了，FCKEditor就是一种。
最牛b的还是comboBox和Grid的结合了，可以分页。
web交互设计可以讲很多，下次一个个HTML元素讲过去。讲为什么HTML元素这么设计，设计目的是为了哪种交互。接着讲各种优秀的html组件封装，能实现哪种交互。讲解思维是，只讲它们的好，它们的不好放到后面讲。比如先讲select标签的作用是什么，再讲comboBox的作用是什么，他俩都有同样的功能，但是后者弥补了前者哪些不足，从而引出前者的不足。
交互设计的结果就是，1.交互设计很好，用户很快找到信息，迅速离开，下次再来，就像以前的google，很无私。2.交互设计很差，用户不堪忍受，迅速离开，不想再来。3.交互设计很好，用户被惊艳到了，流连其中，同样的功能，下次再来。
组件的数据源，最古老的方式是，后台脚本语言生成html标签，然后插入html页面。比如php获取数据库数据，与<option>标签混合，然后传到前台页面。
自从出了xml，json，微软的odata后，就不这么干了。把数据封装成json等格式，传到前台。前台自己组合html标签。
KendoUI就这么干，以前微软的asp.net也这么干，不过他是自家的odata格式。和自家的asp.net控件标签。可以看到，KendoUI是仿微软asp.net控件，但比微软asp.net控件做得更优雅，更容易扩展，自定义。
题外话，代码设计,Knockout与jQuery的数据绑定不同，导致代码逻辑的不同。
jQuery是单向数据绑定，比如页面加载时，点击按钮时等等。首先遍历整个DOM结构，找出Element，进行修改，很自然。相关联的变化，再遍历咯，再找咯，再修改咯。思路很自然，不费脑。
Knockout是双向数据绑定。意味着什么，在单向数据绑定里面再封装了一层，封装表示你可以暂时放下jQuery数据绑定思维。改了这个，依靠这个的那个，自然改咯。
可证明式设计，
比如说一个符合图灵机理论的程序语言，能写出编译自己的编译器。
就连符合关系型理论的数据库设计，你改了这个某表的某主键的某一行内容，对应着外键内容也改掉。当然可以不改，等着关系型理论报错吧。 NoSQL？自然就是滚你的关系型理论，哥宁愿数据展示错误，也要方便读取大量数据。因为关系数据库里面的数据越多，表示关系越错综复杂，关系多了么，增删改就受到牵制了，牵制了也就慢了。
那程序设计呢？
有没有什么理论，说我按照这个理论设计的程序，如果出错只会出这几种错误。
面向对象设计模式？算了吧，那只是为了扩展性而服务。为了应付业务开始复杂了，代码也能随着业务而复杂。
Combobox是不错了，但由于Combobox有数据绑定问题，比如初始化Combobox时，没有绑定DataSource，到后来用$().data("kendoComboBox").dataSource=kendoDataSource，进行Datasource绑定，再refresh下。嗯，下拉列表是有了，但filter只支持startwith，不支持contains。解决这个问题，就声明一个全局DataSource，重新初始化整个KendoComboBox()了。