Question

我现在和Backbone.js一起工作了一段时间，我现在遇到的其中一件事情是;有时您需要将服务器端逻辑放入.eco.jst模板

例如

一个i18n翻译（目前正在查看i18n.js gem）
路径没有硬编码的路径（somemodel_path（somemodel））
授权（例如，如果用户可以销毁此模型，则显示删除按钮）。 Atm我通过在json中传入一些权限对象来解决这个问题。
渲染一个像simple_form或S3_file_uploader这样的html帮助器（atm我解决了这个问题，将其渲染到服务器端，并将显示放在没有）

如您所知，.eco由node.js解析，因此我无法在eco文件中调用ruby。我通过在头部基本创建“数据”对象来解决大多数这些问题。与此类似：

window.data = {
    some_translation = "<%= t('cool') %>",
    <%= "can_destoy_model = true," if can?('destroy', Model) %>
    post_edit_link = "<%= post_path(@post) %>
}

除了这个笨重之外（这只是一个例子，通常这会更加强大，或者我将html5数据属性添加到某个dom元素），这很耗时，有时候你必须重新创建完整的业务逻辑，否则这将是一个rails中的oneliner（例如S3_file_uploader，需要编码的amazon policyfile和令牌）

您对此有何看法？我是否应该使用.eco（虽然我喜欢单独文件中的模板而不是查看视图）。如果我使用胡子或把手，我会使用服务器端逻辑吗？如果是这样，你会推荐哪种宝石？

Answer 1

我对Backbone.js的体验有限，但我设法使用以下宝石设置了无逻辑模板的环境：

还有其他一些东西，甚至是我正在处理的迷你框架（你可以找到它here）

我选择使用Backbone构建Single Page Applications的方法。

基本上，haml_assets gem为sprockets提供了解析.haml文件的能力，这不是必需的，但我喜欢HAML语法。 handlebars_assets gem提供了解析Handlebars模板的方法，包括服务器端和客户端。你可以在模板中使用Ruby代码，你可以解决你提到的i18n和路径方法问题。

我发现这些工具非常适合帮助DRY创建应用程序模板，它可以帮助您在模板中添加逻辑。例如，如果您使用Backbone Views来决定是否显示delete按钮，您可以将逻辑保留在Backbone View中，并使用该逻辑来呈现正确的Handlebars模板（或部分）

使用您的示例：

CoffeeScript的：

class ProjectShowView extends Backbone.View
  template: (context) -> HandlebarsTemplates['projects/show'](context)
  deleteButtonTemplate: (context) -> HandlebarsTemplates['projects/shared/delete_button'](context)

  render: (canDelete = false) ->
    @$el.html(@template(@model.toJSON()))
    @$('.delete_button_container').append(@deleteButtonTemplate()) if canDelete
    @

这个例子非常原始和基本，但可以指向正确的方向。我希望它有所帮助！

混合客户端javascript模板与rails.js的rails逻辑

1 个答案: