要解決這個問題，開發(fā)者發(fā)現(xiàn)了一種名為“事件委派”的技術(shù)。你可以在容器元素上注冊 一個監(jiān)聽器并使用 event.target 來識別哪個元素是用戶點擊的，而不是為問題中的 每個項目創(chuàng)建一個監(jiān)聽器。

實現(xiàn)這有一些微妙，因為一些事件（比如 focus 、 blur 和 change ）不會冒 泡。幸運的是，jQuery 已經(jīng)徹底解決了這個問題；用 jQuery 的 on 方法可以可靠 地處理所有原生瀏覽器事件。

其它 JavaScript 框架用兩種方法中的其一來處理這個問題。第一種是，它們要你自己 實現(xiàn)原生解決方案，為每個項目創(chuàng)建獨立的視圖。當你創(chuàng)建視圖，它在視圖的元素上設 置一個監(jiān)聽器。如果你有一個含有 500 個項目的列表，你會創(chuàng)建 500 個視圖并且每個 視圖都會在它自己的元素上設置一個監(jiān)聽器。

第二種方法是，框架在視圖層內(nèi)置事件委派。當創(chuàng)建一個視圖，你可以提供一個事件列 表來在事件發(fā)生時委派一個方法來調(diào)用。這只剩下識別接受事件的方法的點擊上下文 （比如，列表中的哪個項目）。

你現(xiàn)在要面對兩個令人不安的選擇：為每個項目創(chuàng)建一個新視圖，這樣會喪失事件委派 的優(yōu)勢，或是為所有項目創(chuàng)建單個視圖，這樣必須存儲 DOM 中底層 JavaScript 的信息。

要解決這個問題，Ember 用 jQuery 把所有事件委派到應用的根元素（通常是文檔的 body ）。當一個事件發(fā)生，Ember 識別出最近的處理事件視圖并調(diào)用它的事件處理 器。這意味著你可以創(chuàng)建視圖來保存一個 JavaScript 上下文，但仍然從事件委派上受 益。

進一步地，因為 Ember 只為整個 Ember 應用注冊一個事件，創(chuàng)建新視圖永遠都不需要 設置事件監(jiān)聽器，這使得重渲染高效且免于出錯。當視圖有一個子視圖，這也意味著不 需要手動取消委派重新渲染過程中替換掉的視圖。

渲染管道

大多數(shù) web 應用用特殊的模板語言標記來指定它們的用戶界面。對于 Ember.js，我們 已經(jīng)完成用可在值修改的時候自動更新模板的 Handlebars 模板語言來編寫模板。

雖然顯示模板的過程對開發(fā)者是自動的，但其遮蓋了把原始模板轉(zhuǎn)換為最終模板、生成 用戶可見的 DOM 表示的一系列必要步驟。

這是 Ember 視圖的近似生命周期： 

1. 模板編譯

應用的模板通過網(wǎng)絡加載或以字符串形式作為應用的載荷。當應用加載時，它發(fā)送模板 字符串到 Handlebars 來編譯成函數(shù)。一經(jīng)編譯，模板函數(shù)會被保存，且可以被多個視 圖重復使用，每次都它們都需重新編譯。

這個步驟會在應用中服務器預編譯模板的地方發(fā)出。在那些情況下，模板不作為原始的 人類可讀的模板傳輸，而是編譯后的代碼。

因為 Ember 負責模板編譯，你不需要做任何額外的工作來保證編譯后的模板可以重用。

#p#

2. 字符串的連接

當應用在視圖上調(diào)用 append 或 appendTo 時，一個視圖渲染過程會被啟動。 append 或 appendChild 調(diào)用 安排 視圖渲染并在之后插入。這允許應用中的 延遲邏輯（譬如綁定同步）在渲染元素之前執(zhí)行。

要開始渲染過程，Ember 創(chuàng)建一個 RenderBuffer 并把它呈遞給視圖來把視圖的內(nèi)容 附加到上面。在這個過程中，視圖可以創(chuàng)建并渲染子視圖。當它這么做時，父視圖創(chuàng)建 并分配一個 RenderBuffer 給子視圖，并把它連接到父視圖的 RenderBuffer 上。

Ember 在渲染每個視圖前刷新綁定同步隊列。這樣，Ember 保障不會渲染需要立即替換 的過期數(shù)據(jù)。

一旦主視圖完成渲染，渲染過程會創(chuàng)建一個視圖樹（即“視圖層級”），連接到緩沖區(qū)樹 上。通過向下遍歷緩沖區(qū)樹并把它們轉(zhuǎn)換為字符串，我們就有了一個可以插入到 DOM 的字符串。

這里是一個簡單的例子： 

除子節(jié)點之外（字符串和其它 RenderBuffer ）， RenderBuffer 也會封裝元素標 簽名稱、id、class、樣式和其它屬性。這使得渲染過程修改這些屬性（例如樣式）成 為可能，即使在子字符串已經(jīng)渲染完畢。因為這些屬性的許多都可以通過綁定（例如用 bindAttr ）控制，這使得渲染過程穩(wěn)健且透明。

3. 元素的創(chuàng)建和插入

在渲染過程的最后，根視圖向 RenderBuffer 請求它的元素。 RenderBuffer 獲得 它的完整字符串并用 jQuery 把它轉(zhuǎn)換成一個元素。視圖把那個元素分配到它的 element 屬性并把把它放置到 DOM 中正確的位置（ appendTo 指定的位置，如果 應用使用 append 即是應用的根元素）。

雖然父視圖直接分配它的元素，但每個子視圖惰性查找它的元素。它通過查找 id 匹 配它的 elementId 屬性的元素來完成這。除非顯式提供，渲染過程生成一個 elementId 屬性比你更分配它的值給視圖的 RenderBuffer ，RenderBuffer 允 許視圖按需查找它的元素。

4. 重新渲染

在視圖把自己插入到 DOM 后，Ember 和應用都會要重新渲染視圖。它們可以在視圖上 調(diào)用 rerender 方法來出發(fā)一次重渲染。

重新渲染會重復上面的步驟 2 和步驟 3，有兩點例外：

• rerender 用新元素替換已有的元素，而不是把元素插入到顯式定義的位置。
• 除了渲染新元素，它也刪除舊元素并銷毀它的子元素。這允許 Ember 在重新渲染視 圖時自動處理撤銷合適的綁定和觀察者。這使得路徑上的觀察者可行，因為注冊和撤銷 注冊所有的嵌套觀察者都是自動的。

最常見的導致視圖重新渲染的原因是當綁定到 Handlebars 表達式（ {{foo}} ）變 更。Ember 內(nèi)部為每個表達式創(chuàng)建一個簡單的視圖，并且在路徑上注冊一個觀察者。當 路徑變更時，Ember 用新值更新那個區(qū)域的 DOM。

另一個常見的情況是一個 {{#if}} 或 {{#with}} 塊。當渲染一個模板時，Ember 為這些塊輔助標創(chuàng)建虛擬的視圖。這些虛擬的視圖不會出現(xiàn)在公共可訪問的視圖層級里 （當從視圖獲取 parentView 和 childViews 時），但它們的存在啟用了一致的重 渲染。

當傳遞到 {{#if}} 或 {{#with}} 的路徑變更，Ember 自動重新渲染虛擬視圖替換 它的內(nèi)容，重要的是，也會銷毀所有的子視圖來釋放內(nèi)存。

除了這些情景，應用有時也會要顯式地重新渲染視圖（通常是一個 ContainerView ，見下）。在這種情況下，應用可以直接調(diào)用 rerender ，且 Ember 會把一項重渲染工作加入隊列，用相同的語義元素。

這個過程像是這樣：

  #p#

視圖層級

父與子

當 Ember 渲染一個模板化的視圖，它會生成一個視圖層級。讓我們假設已有一個模板 form 。

原文鏈接：

 
 
 
 

  
  
  
  
{{view App.Search placeholder="Search"}} 
  
  
  
  
{{#view Ember.Button}}Go!{{/view}} 
 
 
 
 

然后我們像這樣把它插入到 DOM 中：

 
 
 
 

  
  
  
  
var view = Ember.View.create({ 
  
  
  
  
  templateName: 'form' 
  
  
  
  
}).append(); 
 
 
 
 

這會創(chuàng)建一個如下小巧的視圖等級：  

你可以用 parentView 和 childViews 屬性在視圖層級中游走。

 
 
 
 

  
  
  
  
var children = view.get('childViews') // [ ,  ] 
  
  
  
  
children.objectAt(0).get('parentView') // 視圖 
 
 
 
 

一個常見的 parentView 使用方法是在子視圖的實例里。

 
 
 
 

  
  
  
  
App.Search = Ember.View.extend({ 
  
  
  
  
  didInsertElement: function() { 
  
  
  
  
    // this.get('parentView') 指向 `view` 
  
  
  
  
  } 
  
  
  
  
}) 
 
 
 
 

生命周期鉤子

為了容易地在視圖的生命周期的不同點上執(zhí)行行為，有若干你可以實現(xiàn)的鉤子。

• willInsertElement: 這個鉤子在視圖渲染后插入 DOM 之前調(diào)用。它不提供對視圖的 element 的訪問。
• didInsertElement: 這個鉤子在視圖被插入到 DOM 后立即調(diào)用。它提供到視圖的 element 的訪問，且對集成到外部庫非常有用。任何顯式的 DOM 設置代碼應限于這個鉤子。
• willDestroyElement: 這個鉤子在元素從 DOM 移除前立即調(diào)用。這提供了銷毀任何與 DOM 節(jié)點關(guān)聯(lián)的外部狀態(tài)的機會。像 didInsertElement 一樣，它對于集成外部庫非常有用。
• willRerender: 這個鉤子在視圖被重新渲染前立即調(diào)用。如果你想要在視圖被重新渲染前執(zhí)行一些銷毀操作，這會很有用。
• becameVisible: 這個鉤子在視圖的 isVisible 或它的祖先之一的 isVisible變?yōu)檎嬷担谊P(guān)聯(lián)的元素也變?yōu)榭梢姾笳{(diào)用。注意這個鉤子只在所有可見性由 isVisible 屬性控制的時候可靠。
• becameHidden: 這個鉤子在視圖的 isVisible 或它的祖先之一的 isVisible變?yōu)榧僦?，且關(guān)聯(lián)的元素也變?yōu)殡[藏后調(diào)用。注意這個鉤子只在所有可見性由 isVisible 屬性控制的時候可靠。

應用可以通過在視圖上定義一個與鉤子同名的方法來實現(xiàn)鉤子?；蛘?，在視圖上為鉤子 注冊一個監(jiān)聽器也是可行的。

 
 
 
 

  
  
  
  
view.on('willRerender', function() { 
  
  
  
  
  // do something with view 
  
  
  
  
}); 
 
 
 
 

虛擬視圖

正如上文所述，Handlebars 在視圖層級內(nèi)創(chuàng)建視圖來表現(xiàn)綁定值。每次你使用 Handlebars 表達式，無論是一個簡單值還是一個諸如 {{#with}} 或 {{#if}} 的 塊表達式，Handlebars 會創(chuàng)建一個新視圖。

因為 Ember 只把這些視圖用于內(nèi)部簿記，它們對于視圖的公共 parentView 和 childViews API 是隱藏的。公共視圖層級只反射用 {{view}} 輔助標記或通過 ContainerView 創(chuàng)建的視圖（見下）。

例如，考慮下面的 Handlebars 模板：

 
 
 
 

  
  
  
  
Joe's Lamprey Shack
 
  
  
  
  
{{controller.restaurantHours}} 
  
  
  
  
{{#view App.FDAContactForm}} 
  
  
  
  
  如果你在喬的七鰓鰻小屋用餐后不適，請用下面的表格向 FDA 提交申訴。 
  
  
  
  
  {{#if controller.allowComplaints}} 
  
  
  
  
    {{view Ember.TextArea valueBinding="controller.complaint"}} 
  
  
  
  
    提交 
  
  
  
  
  {{/if}} 
  
  
  
  
{{/view}} 
 
 
 
 

渲染這個模板會創(chuàng)建這樣的層級：  

 幕后，Ember 跟蹤為 Handlebars 表達式創(chuàng)建的額外的虛擬視圖：  

 #p#

在TextArea 中， parentView 會指向 FDAContactForm ，并且 FDAContactForm 的 childViews 會是一個只包含 TextArea 的數(shù)組。

你可以通過 _parentView 和 _childViews 來查看內(nèi)部視圖層級，這會包含虛擬視 圖：

 
 
 
 

  
  
  
  
var _childViews = view.get('_childViews'); 
  
  
  
  
console.log(_childViews.objectAt(0).toString()); 
  
  
  
  
//>  
 
 
 
 

警告！ 你不應該在應用代碼中依賴于這些內(nèi)部 API。它們會在任何時候更改并且 沒有任何公共合約。返回值也不能被觀察或被綁定。它可能不是 Ember 對象。如果覺 得有使用它們的需求，請聯(lián)系我們，這樣我們可以為你的使用需求暴露一個更好的公共 API。

底線：這個 API 就像是 XML。如果你覺得你需要用到它，那么你很可能沒有足夠理解 問題。三思！

事件冒泡

視圖的一個任務是響應原始用戶事件并把它們翻譯成對你應用而言有語義的事件。

例如，一個刪除按鈕把原始的 click 事件翻譯成應用特定的“把這個元素從數(shù)組中刪 除”。

為了響應用戶事件，創(chuàng)建一個視圖的子類來把事件實現(xiàn)為方法：

 
 
 
 

  
  
  
  
App.DeleteButton = Ember.View.create({ 
  
  
  
  
  click: function(event) { 
  
  
  
  
    var stateManager = this.getPath('controller.stateManager'); 
  
  
  
  
    var item = this.get('content'); 
  
  
  
  
    stateManager.send('deleteItem', item); 
  
  
  
  
  } 
  
  
  
  
}); 
 
 
 
 

當你創(chuàng)建一個新的 Ember.Application 實例，它用 jQuery 的事件委派 API 給每個 原生瀏覽器事件注冊一個事件處理器。當用戶觸發(fā)一個事件，應用事件分配器會找出離 事件最近的視圖并實現(xiàn)那個事件。

一個視圖通過定義與事件同名的方法來實現(xiàn)事件。當事件名稱由多個詞組成（如 mouseup ）方法名會用 Camel 命名法把事件名作為方法名（ mousUp ）。

事件會在視圖層級中冒泡，直到事件到達根視圖。一個事件處理器可以用與常規(guī) jQuery 事件處理器相同的技術(shù)來停止事件傳播：

• 在視圖中 return false
• event.stopPropagation

例如，假設你已經(jīng)定義了如下的視圖類：

 
 
 
 

  
  
  
  
App.GrandparentView = Ember.View.extend({ 
  
  
  
  
  click: function() { 
  
  
  
  
    console.log('Grandparent!'); 
  
  
  
  
  } 
  
  
  
  
}); 
  
  
  
  
App.ParentView = Ember.View.extend({ 
  
  
  
  
  click: function() { 
  
  
  
  
    console.log('Parent!'); 
  
  
  
  
    return false; 
  
  
  
  
  } 
  
  
  
  
}); 
  
  
  
  
App.ChildView = Ember.View.extend({ 
  
  
  
  
  click: function() { 
  
  
  
  
    console.log('Child!'); 
  
  
  
  
  } 
  
  
  
  
}); 
 
 
 
 

這是使用它們的 Handlebars 模板。

 
 
 
 

  
  
  
  
{{#view App.GrandparentView}} 
  
  
  
  
  {{#view App.ParentView}} 
  
  
  
  
    {{#view App.ChildView}} 
  
  
  
  
      
點擊這里！
 
  
  
  
  
    {{/view}} 
  
  
  
  
  {{/view}} 
  
  
  
  
{{/view}} 
 
 
 
 

如果你點擊

，你會在瀏覽器控制臺里看見下面的輸出：

 
 
 
 

  
  
  
  
Child! 
  
  
  
  
Parent! 
 
 
 
 

你可以看出 Ember 在接受事件的最深層級視圖上調(diào)用了處理器。事件繼續(xù)上浮到 ParentView ，但不會到達 GrandparentView 因為 ParentView 從它的事件處理 器中返回了 false 。

你可以使用常規(guī)事件冒泡技術(shù)來實現(xiàn)常見的模式。例如，你可以實現(xiàn)一個帶有 submit 方法的 FormView 。因為瀏覽器在用戶向文本域輸入回車的時候會觸發(fā) submit 事件，在表單視圖上定義一個 submit 方法會“剛好完成任務”。

 
 
 
 

  
  
  
  
App.FormView = Ember.View.extend({ 
  
  
  
  
  tagName: "form", 
  
  
  
  
  submit: function(event) { 
  
  
  
  
    // 會在任何用戶觸發(fā)瀏覽器的 
  
  
  
  
    // `submit` 方法時被調(diào)用 
  
  
  
  
  } 
  
  
  
  
}); 

 
 
 
 

 
 
 
 

  
  
  
  
{{#view App.FormView}} 
  
  
  
  
  {{view Ember.TextFieldView valueBinding="controller.firstName"}} 
  
  
  
  
  {{view Ember.TextFieldView valueBinding="controller.lastName"}} 
  
  
  
  
  確定 
  
  
  
  
{{/view}} 
 
 
 
 

#p#

添加新事件

Ember 內(nèi)置了如下原生瀏覽器事件的支持：

事件名	方法名
touchstart	touchStart
touchmove	touchMove
touchend	touchEnd
touchcancel	touchCancel
keydown	keyDown
keyup	keyUp
keypress	keyPress
mousedown	mouseDown
mouseup	mouseUp
contextmenu	contextMenu
click	click
dblclick	doubleClick
mousemove	mouseMove

事件名	方法名
focusin	focusIn
focusout	focusOut
mouseenter	mouseEnter
mouseleave	mouseLeave
submit	submit
change	change
dragstart	dragStart
drag	drag
dragenter	dragEnter
dragleave	dragLeave
dragover	dragOver
drop	drop
dragend	dragEnd

當你創(chuàng)建一個新應用時，你可以向事件分配器添加額外的事件：

 
 
 
 

  
  
  
  
App = Ember.Application.create({ 
  
  
  
  
  customEvents: { 
  
  
  
  
    // 添加 loadedmetadata 媒體播放器事件 
  
  
  
  
    'loadedmetadata': "loadedMetadata" 
  
  
  
  
  } 
  
  
  
  
}); 
 
 
 
 

要使這能對自定義事件奏效，HTML5 規(guī)范必須定義事件為“bubbling”，否則 jQuery 必 須為這個事件提供一個事件委派折中方案。

模板化視圖

如同迄今你在本指導中所見，你在應用中會用的大多數(shù)視圖是依靠模板的。當使用模板 時，你不需要編寫你的視圖層級，因為模板會為你創(chuàng)建它。

渲染時，視圖模板可以把視圖附加到它的子視圖數(shù)組中。模板的 {{view}} 輔助標記 內(nèi)部會調(diào)用視圖的 appendChild 方法。

調(diào)用 appendChild 會做兩件事：

1. 把視圖添加到 childViews 數(shù)組。
2. 立即渲染子視圖并把它添加到父視圖的渲染緩沖區(qū)。

你不應該在視圖離開渲染狀態(tài)后調(diào)用
appendChild 。模板渲染出“混合內(nèi)容”（包含 視圖和純文本），所以當渲染過程完成后，父視圖不知道到底把新的子視圖插入到哪 里。

 在上例中，想象試圖把一個新視圖插入到父視圖的 childViews 數(shù)組中。它應該立即 放在 App.MyView 的閉合標簽