爲什麼大家仍然在使用渲染方法構建父子視圖？

我敢說自己是一名骨幹黑客。我知道框架可以做什麼，以及它的侷限性在哪裏。我也有一些模板框架的經驗。爲什麼大家仍然在使用渲染方法構建父子視圖？

我見過很多教程，其中人們解釋瞭如何創建複雜和嵌套的視圖，其中大多數構造它有點部分使用模板，然後在父視圖的渲染方法中，爲了將模板化子意見

對我來說，這是沒有意義的，爲什麼我們應該在聲明性代碼中處理佈局渲染。來自Flex，我被教導永遠不會這樣做。我總是將佈局描述和變量綁定留給標記，然後將事件處理留給使用此標記的聲明式（View實例）代碼。

但是，我測試的模板框架都不允許使用嵌套視圖創建複雜標記。我們無法真正從模板中調用模板，從而實例化一個View對象。這在技術上似乎是可行的，尤其是使用數據屬性，我們可以在其中指定類型名稱。

然後，根級別View類所需的所有渲染方法都是將此模板轉換爲HTML標記，然後找出子對象的類型應該是什麼類型，爲它們中的任何一個創建子視圖實例，並進一步保持，以防這些子對象本身應有子對象。每個視圖都有一個模型上下文。基本上所有我們一直處理的樣板步驟，但在Backbone.View級別自動化。

其他人在想這個嗎？爲什麼沒有人似乎在使用這個？

來源

2011-11-26 user802232

[三位一體做複雜的標記與嵌套視圖]（https://github.com/Raynos/trinity）。您還可以輕鬆預處理三位一體視圖，爲所有嵌套視圖創建Backbone視圖對象。你的概念的問題是你需要一個體面的模板系統，允許強大的繼承，這是罕見的。 – Raynos

我有一種感覺，這屬於其他地方，它不是一個可以解決你的代碼定義的問題，它更多的是與父母的孩子的意見最佳實踐的討論......我因此傾向於看到這更多的是一個討論比問答話題。也許社區維基的東西？ – Sander

雖然我不知道你的特定問題，但應該注意的是，Java的AWT庫的行爲與你描述的方式相反。佈局管理員定位元素的控件列表。遞歸呈現子對象以構建控件/容器樹。在使用Handlebars.js在Backbone中構建了遞歸渲染視圖後，我更喜歡使用更優雅的基於代碼的解決方案，而不是試圖破解似乎總是需要自定義模板操作的模板。 – Max

需要注意的是，根本不需要使用渲染，它主要用於在對代碼進行更改之後重新渲染。您可以根據CSS選擇器直接綁定視圖（請參閱文檔）。

此外，Backbone還有一個模型綁定擴展，大大簡化了數據綁定並減少了所需的「手動」勞動。你可能想看看它。

http://github.com/derickbailey/backbone.modelbinding

最後我要說的是有關呈現的父子關係。 Do not call the DOM in a loop。這是非常低效的，並且至少有一個原因是人們只會在父母提供方法的情況下建立親子關係。讓每個孩子使用jQuery說明會導致瀏覽器工作很多（如果你沒有注意到這是在現代瀏覽器中使用IE8的話）。

來源

2011-12-04 02:43:26

我同意在render方法中實例化子視圖是沒有意義的。雖然初始化子視圖的時候，我會猶豫，完全自動化的過程，因爲我經常要在其他參數傳遞例如：

var childCollection = someLogicToCreateTheChildCollection(); 

new ChildView({ 
    collection : childCollection 
});

所以，我最終會做，而不是創造我不需要任何的子視圖在initialize，然後在render我渲染模板並將子視圖分配給DOM中的元素。

這樣我的渲染功能是不是一個聲明DOM順序（像很多的例子表明通過追加）-The模板設置DOM秩序和渲染功能只是setElement().render()的孩子的意見。

來源

2012-05-07 14:31:30

爲什麼大家仍然在使用渲染方法構建父子視圖？

回答

相關問題