我正在將Backbone和Backbone.Marionette集成到現有的Web應用程序項目中。我們計劃現在只保留項目中的所有現有功能,但是我們將利用Backbone架構和Marionette校長的任何新功能。首要業務之一是決定HTML模板渲染庫以及這些模板的數據綁定解決方案。以前,我們一直在使用JsRender和JsViews來滿足我們所有的模板需求和數據綁定,但我們願意探索新功能的新途徑。所以基本上我一直在研究各種解決方案,現在需要一些關於選擇什麼的建議或想法。以下是我已經看過了迄今:骨幹:模型到模板和模板到模型綁定
優點:似乎遵循的關注點分離骨幹的想法,這有助於保持你的模板非常「乾淨」。
缺點:看起來你必須在你的視圖中多寫一些代碼來定義綁定。此外,似乎缺乏執行條件呈現的功能,因此您必須始終呈現完整模板並切換某些元素的顯示。
優點:處理更多的數據綁定模板中的選項沒有使它太亂。
缺點:另外,似乎缺乏條件渲染。
優點:處理各種數據,通過屬性綁定需要的。
缺點:易於開始使用轉換器「模糊」模板。必須添加另一步從Backbone模型創建Knockout視圖模型。
優點:類似淘汰賽的能力,但不同的語法。處理條件呈現。
缺點:在過去,我們通過在模板中添加太多業務邏輯來弄髒我們的模板,但這可能是我們開發中可以糾正的一個問題。需要創建功能以將JsViews的可觀察性功能與Backbone模型事件聯繫起來。其他類似StickIt和Knockback的庫會自動處理這個問題。
我們還調查了Backbone.ModelBinder這是介於兩者之間StickIt和鉚釘。
任何人都可以分享他們做出的任何決定,他們爲什麼選擇一個插件/庫而不是另一個?我也接受其他建議。謝謝。
我簽出了下劃線(有趣的是,我沒有考慮它包括像你提到的)。我覺得我們可能會遇到與「意大利麪條」模板相同的問題。主要關注的是我們有許多開發人員在開發模板,我們開始將太多的邏輯和模板語法交織在HTML中。所以爲了迫使我們放棄這種習慣,我們選擇了Backbone.Stickit。看起來需要一段時間才能習慣在模板之外創建綁定,但希望我們可以從HTML的「清潔」中受益。感謝您的輸入。 – 2013-02-11 17:26:15