我應該在哪裏使用模板，我應該在哪裏編程生成視圖對象？

Question

我正在使用Backbone.js進行涉及很多不同視圖的應用程序，其中一些嵌套其他視圖，而這些其他視圖可以進一步嵌套其他視圖。

還可以查看錶現取決於模型中的某些屬性，例如，如果用戶已經通過認證只顯示一些內容，或者另一種類型的，如果檢查

從Adobe的Flex的世界的到來，我習慣使用標記甚至是深度嵌套或複合標記來幾乎完全地聲明我的視圖。 Flex使得標記中的組件聲明變得小菜一碟。

我有點希望我能達到同樣的那種純粹的觀點介紹和骨幹視圖邏輯之間的分離，但到目前爲止，我一直在與掙扎。

這樣做的原因是，我無法設法僅使用模板聲明覆合視圖。因此，我不得不求助於使用BB的render（）方法來實例化子視圖並將它們附加到父視圖。這沒關係......但如果視圖變得非常精細，那麼使用JS聲明它是一種矯枉過正的行爲，因爲我從字面上最終會追加純HTML字符串，這完全是一團糟。這意味着對這些模板使用模板會更好，然後只是渲染模板而不是使用JS來完成所有的工作。

使用這兩種方法只是打破了應用程序中的任何一致性，但我強迫自己做得很好，因爲我已經閱讀了很多（甚至是專業編寫的）主幹代碼，而且我看到其他人正在努力一樣的東西。

如果我不能避免這種分離的渲染方法，那麼至少我將不得不把任何特定的界線，這些意見應與模板進行渲染，並沒有，或者只是部分。問題是這些標準是什麼。

Answer 1

我的方法是將所有標記包含在模板中。

我的骨幹視圖的概念是它們實際上是控制器。如果您在更傳統的Web應用程序框架中考慮Controller，他們的工作是接收事件，編組模型，獲取和呈現模板，傳入模型以及返回結果輸出。

在Backbone中，視圖是負責此任務的元素。但是，DOM不是輸入/輸出媒體，而是輸入/輸出媒體。

因此，我認爲Views是屏幕上UI特定區域的控制器。他們監聽事件，元帥模型，獲取和渲染模板，並修改DOM。

的時候去生成一個子視圖與也許在循環執行模板的麻煩的決定，對我來說是相當寬鬆的。

如果它有可能在多個視圖中使用，那麼我會查看它。

如果有任何事件或影響自身的用戶交互，但沒有真正的「父」對象什麼我將做一個觀點出來。

如果它有任何真正的邏輯，我會看看它。

如果它的相關模型或集合，我會從中看出來。

但是，在任何這些情況下，視圖不會直接生成HTML - 我會始終將標記存儲在模板中。