動態可配置表單的設計構思

1、引言

   在瀏覽網站的時候，我們經常會提交一些資訊，這些資訊也被叫做“表單”，提交資訊專業一點也叫做提交表單。

   通常會提交的資訊就是註冊資訊，登入資訊，登陸之後還需要提交詳細的個人資訊，其中就會包括學曆，地址，項目經驗等等。

   還有就是在電商網站，我們還會提交訂單，添加收藏，添加購物車。

   在網路中，我們每天都會遇到各種各樣的表單，隨著網路的普及，資訊化的普及，很多資訊都是通過網路提交的，我們會頻繁的和表單打交道。

那麼什麼是表單呢？

   表單指的是使用者在頁面中填寫的資訊的總和，也是填寫的資訊項的總和。表單的主要作用是收集資訊。

   在百度百科中是這麼解釋的。

表單在網頁中主要負責資料擷取功能。一個表單有三個基本組成部分：

1、表單標籤；

2、表單域，包含了文字框、密碼框、隱藏欄位、多行文字框、複選框、單選框、下拉選擇框和檔案上傳框等；

3、表單按鈕。

2、表單的設計

2.1、靜態表單

   表單所有的表單項事先已經固定，比如說有多少個表單項，每一項都是什麼類型，那些需要不會再前台顯示，這些表單項的排序，顯示的控制，大多是固定的。

   在應用開發完成之後，如果需要修改表單項，比如說增加表單項，調整表單項的顯示位置。表單項分組顯示，分組控制。這些都會需要修改代碼，甚至是修改資料庫才能滿足要求。

   所有人都希望表單是動態，動態管理表單項。

2.2、動態表單

2.2.1、第一種

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1121304A5-0.png" style="float:none;" title="1.png" />

優點：

   簡單明了。

   配置簡單。

缺點：

   表單資訊沒有分類，不便於顯示控制。比如說個人資訊中的基本資料，學曆資訊，聯絡資訊，不能動態分塊顯示。

   屬性不能複用。比如說學曆資訊，聯絡資訊，其實個人表單和企業表單，甚至其他表單也會用到，沒有必要重複配置。

2.2.2、第二種

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/1121301936-1.png" title="2.png" style="float:none;" />

缺點：

   沒有支援表單的模板化。

優點：

   配置更靈活，不複雜。

   支援屬性群組的複用。比如說學曆資訊屬性群組，連絡方式屬性群組。

   屬性群組可以排序，控制顯示。

2.2.3、第三種

650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131228/112130F14-2.png" title="3.png" style="float:none;" />

缺點：

   配置複雜，稍顯冗餘。

   不容易理解。

優點：

   靈活，強大。

   最大化支援動態表單的動態配置需要。

   相同表單，支援多個模板，支援啟用與禁用模板。

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的索引值對，一組，然後再添加單選或者多選表單項的時候，選擇資料來源來填充表單項。

本文出自 “突破中的IT結構師” 部落格，請務必保留此出處http://virusswb.blog.51cto.com/115214/1287768