Yahoo!用戶界面博客（YUIBlog）

在銳3畫廊：批量編輯器部件

銳3 DataTable的 快速編輯插件，可以很容易地編輯整個頁面作為一個原子操作的記錄。 然而，有時你需要做的，甚至更多。 例如，你可能有更多的記錄比你可以輕鬆地適應在一個頁面上同時編輯。 或者你可能需要支持添加，複製，刪除記錄作為原子操作的一部分。 或者你可能想在視覺組字段放置在一個單一的表細胞。 批量編輯器部件支持所有這些可能性。

（ 點擊玩這個例子的截圖 。）

概觀

批量編輯構件由三部分組成：

Data source

這包裝一個YUI DataSource和管理的變化：插入，刪除，更改後的值。

Base widget

這提供管理記錄，並在每個記錄中的字段編輯的​​基本結構。 派生類是負責渲染成一個單獨的行 ，這可能是一個div，TBODY，或其他容器的每個記錄。

HTML table implementation

這延伸到TBODY呈現在一個HTML表中每個記錄的基礎構件。 決定哪些字段顯示在表中的每一列列配置。 可用於自定義單元格格式化，呈現在一個單一的表單元格中的多個領域。

組態

在這個例子中，生成上面的截圖，配置一直保持盡可能簡單：

fields定義在每個記錄中可編輯的值。 輸入默認的類型。 有效的其他類型的選擇和 textarea。 （ 選擇需要的值列表。）基本驗證所提供的表格經理畫廊模塊。 這包括所需的字段，長度的限制，和數值範圍 。 更複雜的驗證，可以由指定regex或自己的函數（ fn ）。 這裡是一個活生生的例子摘錄：

 VAR領域=
 {
	標題：
	 {
		類型：'textarea的'
	 }，
	年：
	 {
		驗證：
		 {
			 CSS：'yiv的整數：[1500,2100]“
		 }
	 }，
	顏色：
	 {
		 '選擇'，類型：
		值：
		 [
			 {值：“紅”，文字：'紅'}，
			 {值：“綠色”，文字：“綠色”}，
			 {值：“藍”，文字：'藍'}
		 ]
	 }
 };

Y.BulkEditDataSource需要的一個實例Y.DataSource以下參數：

uniqueIdKey

一鍵唯一標識每條記錄的名稱。

generateRequest

函數產生的請求參數Y.DataSource 。 （這是空的，因為在這個例子Y.DataSource.Local總是返回的所有數據。）

extractTotalRecords

一個函數來提取記錄總數從Y.DataSource響應。

例如使用Y.DataSource.Local ， totalRecordsReturnExpr也是必需的。 該OGNL表達式指定在響應存儲的記錄總數。 （請注意， extractTotalRecords讀取該值。）

 VAR DS =新Y.BulkEditDataSource（
 {
	 DS：raw_ds，
	 uniqueIdKey：'身份證'，
	 generateRequest：函數（）{}
	 totalRecordsReturnExpr：'meta.totalRecords“
	 extractTotalRecords：函數（響應）
	 {
		返回response.meta.totalRecords;
	 }
 }）;

Y.HTMLTableBulkEditor需要的數據源，現場配置，列配置。 列中的配置，關鍵是字段的名稱，除非您指定一個自定義的格式化。 標籤被用作列標題。 這裡是一個活生生的例子摘錄：

 VAR列=
 [
	 {
		鍵：“複選框，
		標籤：的<input type="checkbox" id="select-all" />'，
		格式化函數（O）
		 {
			 VAR標記<input type="checkbox" class="record-select" id="{id}" />';
			 o.cell.set（'innerHTML的“，Y.Lang.sub（標記，
			 {
				 ID：this.getRecordId（o.record）
			 }））;
		 }
	 }，
	 {鍵：'標題'，標籤：“標題”}，
	關鍵：“今年'標籤：'年'}，
	 {鍵：“顏色”標籤：“顏色”}
 ;

（需要注意的是活生生的例子定義了一個小擴展到Y.HTMLTableBulkEditor處理複選框列）。

你也可以傳遞一個的實例Y.Paginator到Y.BulkEditDataSource 。 在一個單獨的，更複雜的活生生的例子說明了這一點。

本地與遠程數據源

當決定是否要使用本地或遠程數據源，你必須仔細考慮權衡。 明顯的權衡是本地的數據源時，分頁，但初始頁面加載需要更長的時間，它需要在客戶端上更多的內存。

批量編輯部件施加額外的取捨，但是。

首先，YUI的數據源必須返回不可變的數據。 這是本地數據源的自動的，但可能會非常棘手實現遠程數據源。 您將需要批量編輯操作的持續時間鎖定數據庫中的表行，如果多個用戶可以修改他們。

第二，本地和遠程數據源之間的選擇會影響你如何保存數據。 當您使用本地數據源，你可以做最省力 ，即，保存到服務器的所有有效的記錄，他們從本地的數據源中刪除，並允許用戶把重點放在有無效值的記錄。 當您使用遠程數據源的，不可改變的要求只允許你做的所有或任何節能，即，數據只能被保存後，所有的數據是有效的。

現實世界中使用案例

批量編輯器部件的原始動機是允許上傳的電子表格後處理。 引入後的處理步驟，消除了需要電子表格值是完美的。 錯誤可以是標記和固定的，而不是拒絕整個上傳批量編輯器部件。 此外，在服務器上進行處理，可以做到每個記錄所需的附加價值的最佳猜測分配，用戶可以保存前檢查和修復這些額外的價值。 這簡化了初始創建的電子表格。

在這種情況下，遠程數據源是最好的選擇。 上傳的數據存儲在一個臨時空間，因此，保證不可改變的，因為沒有其他用戶可以看到它。 “全有或全無”節能是適當的：一旦所有的錯誤已得到修復，保存操作是原子的，就像一個標準的上載操作。

關於作者簡介：： 約翰Lindal （ @ jafl5272在Twitter）是雅虎建設的基礎上率先工程師之一 APT是建成。 此前，他曾在雅虎出版商網絡。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！