我正在将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