1、引言
在瀏覽網站的時候，我們經常會提交一些信息，這些信息也被叫做“表單”，提交信息專業一點也叫做提交表單。
通常會提交的信息就是注冊信息，登錄信息，登陸之后還需要提交詳細的個人信息，其中就會包括學歷，地址，項目經驗等等。
還有就是在電商網站，我們還會提交訂單，添加收藏，添加購物車。
在網絡中，我們每天都會遇到各種各樣的表單，隨着網絡的普及，信息化的普及，很多信息都是通過網絡提交的，我們會頻繁的和表單打交道。
那么什么是表單呢？
表單指的是用戶在頁面中填寫的信息的總和，也是填寫的信息項的總和。表單的主要作用是收集信息。
在百度百科中是這么解釋的。
表單在網頁中主要負責數據采集功能。一個表單有三個基本組成部分：
1、表單標簽；
2、表單域，包含了文本框、密碼框、隱藏域、多行文本框、復選框、單選框、下拉選擇框和文件上傳框等；
3、表單按鈕。
2、表單的設計
2.1、靜態表單
表單所有的表單項事先已經固定，比如說有多少個表單項，每一項都是什么類型，那些需要不會再前台顯示，這些表單項的排序，顯示的控制，大多是固定的。
在應用開發完成之后，如果需要修改表單項，比如說增加表單項，調整表單項的顯示位置。表單項分組顯示，分組控制。這些都會需要修改代碼，甚至是修改數據庫才能滿足要求。
所有人都希望表單是動態的，動態管理表單項。
2.2、動態表單
2.2.1、第一種
優點：
簡單明了。
配置簡單。
缺點：
表單信息沒有分類，不便於顯示控制。比如說個人信息中的基本信息，學歷信息，聯系信息，不能動態的分塊顯示。
屬性不能復用。比如說學歷信息，聯系信息，其實個人表單和企業表單，甚至其他表單也會用到，沒有必要重復配置。
2.2.2、第二種
缺點：
沒有支持表單的模板化。
優點：
配置更靈活，不復雜。
支持屬性組的復用。比如說學歷信息屬性組，聯系方式屬性組。
屬性組可以排序，控制顯示。
2.2.3、第三種
缺點：
配置復雜，稍顯冗余。
不容易理解。
優點：
靈活，強大。
最大化支持動態表單的動態配置需要。
相同表單，支持多個模板，支持啟用與禁用模板。
2.3、靜態+動態
部分靜態表單+動態表單
3、總結
以上是我設想的三種動態表單的實現方式，圖中是數據存儲的簡單表述。
如果大家有其他的方式，也請留言。如果允許，我將會補充在本文的后面。
共享出來，可以幫助更多的人，讓我們一起努力，將動態表單的實現設計的更好更強大。
后記
2013-09-03 14:40
動態表單的設計，除了要考慮存儲，還要考慮查詢。保存的數據如何查詢，因為原來是列級別的數據，現在都被行化了。
舉個例子：開始我們會設計一張表，有姓名列，性別列，簡介列。但是現在是姓名行，性別行，簡介行。如果是關系數據庫，原來的常規查詢SQL都會失效，怎么辦呢？是用特殊方式實現，還是將這些數據導出到常規數據庫設計中，用老方法查詢。
這可能會用到OLTP（在線聯機事務處理）和OLAP（在線聯機分析處理）的概念。
還 有一種辦法，就是講應用分為兩個部分，命令與查詢。命令包括：增刪改，是對數據的維護。查詢就是獲取數據，可能包括各種獲取接口，獲取參數，獲取維度。這 方面比較有名的就是CQRS(Command Query Responsibility Segregation命令查詢職責分離）。可以將它擴展到系統設計上來。
還有就是Field的類型眾多，有一些類 型的儲存還是需要琢磨一下的。常規的單行文本也就是直接存儲一個值就可以了，單多選類型需要存儲的是key，尤其是都選，需要存儲的是多個選中項的 key，多個的個數是不定的，這些key是存儲在一列中，還是用行來存儲，這也是一個撓頭的地方！！！
其實個人還有 一個想法。#數據庫#CRUD,create,read,update,delete到底是不是增刪改查呢？我想大家對於其中的read是否等於差是有一 些疑惑的！read按照字面來說就是讀取，讀取和查詢還是有區別的吧。個人覺得讀取！=查詢，read只是單個數據的獲取，查詢是有條件的多行數據的獲 取。所以說CRUD不是增刪改查，更應該叫做增刪改讀。
表單項還可能是一個樹形的選擇項，對於這方面還沒有想出好的解決方案。只是覺得應該封裝成一個獨立控件，對於樹形選項的數據加載，選擇之后的存儲，已經將來的匹配查詢，都應該有一整套的封裝。比如說精確單編號匹配，多編號匹配，層級匹配等等。
還有一些表單項是單多選是結合的，比如說第一級是只能選擇單個，下一級就可以選擇多個了。
還有一些樹形表單項是只能在葉子節點多選。
單選和多選的表單項的具體項可以從數據源中加載。先設置數據源，也就是一些key/value的鍵值對，一組，然后再添加單選或者多選表單項的時候，選擇數據源來填充表單項。