輸入的交互設計，與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()了。