8

首先在 Programmers.SE 上输入此内容，但想象一下这可能更适合这里 - 纯粹是因为它不是就特定技术问题寻求建议。随意投票移动吧！

我目前正在开发一个使用 Ruby on Rails 的“Spree”电子商务平台的项目。配置和使用是一种完全的乐趣。然而，喜悦就此止步。

我正在尝试开发一个完全自定义的界面 - 一个与默认配置完全没有相似之处的界面。现在 Spree 文档表明我只有两个选择：

  1. 使用deface覆盖。到处。似乎覆盖了其他覆盖。
  2. 完全重建视图。

自然地，使用 deface 对风格进行如此戏剧性的改变是一场彻头彻尾的噩梦。Deface重新编写完整的 UI 看起来不像是一种可接受的方式；也不是很有效。所以我选择完全重建视图。

然后意识到大约有 8 个插件都依赖于 deface 覆盖，视图文件是硬编码的，目标选择器通常是“ flakey ”（充其量）。

除了 spree 网站上极少的文档之外，我能找到的只是各种会议的幻灯片，这些 - 没有谈话的背景实际上是很少用的。他们似乎都专注于使用 deface overrides 来进行非常简单的更改，而最近的那些似乎已经有一年多了。

我错过了什么吗？有谁知道执行此类操作的最佳实践？我实际上应该在哪里寻找？

4

3 回答 3

5

污损是一场巨大的灾难。整个概念是一个巨大的反模式，它导致了一个完整的、彻底的、不可调试的噩梦。我真的希望 Spree 社区能够摆脱它，尤其是插件，并为应用程序内的视图级自定义提供更好的选项。

在 Spree 中不使用 Deface 的最大缺点是您的自定义代码会偏离 Spree 的“库存”视图代码，并且当您升级 spree 时，您有两个不同的（您的自定义和 spree 默认）版本来协调每次升级狂欢。而且您必须逐个文件地执行该操作。

这很乏味，但我通过在我创建的每个视图中插入注释“开始自定义代码”和“结束自定义代码”来让自己更轻松一些，这些视图中混合了狂欢默认代码和我自己的代码。这使升级过程更加顺畅，但仍然没有简单的答案。

如果 Winston Churchill 是 Rails 开发人员，他会说“Spree 中的视图覆盖是最糟糕的定制形式，除了所有其他形式。”

于 2014-12-10T16:12:39.210 回答
4

我遇到了同样的问题，正如你所建议的，当有很多插件使用 deface 时，最好使用 deface 而不是覆盖整个视图。花了一些时间才知道 spree 的圣地和除了文档之外的指南是 spree 的github 源代码。文档中缺少的任何内容都在这里。

如果要覆盖视图，有两种方法：

1）您想使用新视图完全覆盖它。在这种情况下，我建议不要更改当前源代码中使用的现有结构并添加新的更改。这样，您仍然可以根据 deface 使数据挂钩可用于其他插件，这取决于您的视图的 html 代码结构和标签。

2）使用污损。开始使用 Deface 有点像噩梦，因为没有足够的文档。开始使用 Deface 的最佳方式是github。在 Deface 被替换后测试新视图代码的最重要的实用程序是使用 rake 任务。要查看使用标签选择的元素，请使用： rake deface:test_selector['spree/address/_form','p']- 这会显示在相应视图部分中使用 p 的所有元素。要查看原始部分使用：

rake deface:get_result[shared/_head]

这些在 deface 的 github 中被提及，但它们非常方便，因此强调。

于 2013-10-11T16:39:40.057 回答
4

在讨论了 Spree 用户的邮件列表之后，普遍的共识似乎是：

最好的选择是废弃所有视图覆盖的污损——这可能最好通过分叉 spree-frontend 来实现。

关于插件，事情不会简单——如果不能保留数据挂钩，那么我只需要禁用覆盖并将它们直接实现到视图中。

不是很好，而是两害相权取其轻。通过使用 deface 进行如此戏剧性的更改，您会发现自己陷入了混乱。

讨论还包括一位开发人员提到（非常好的想法）在这样做之后使用 Capybara 进行测试，以确保一切仍然正常工作。每次更新后都会涉及维护，这是@Lavixu 的回答试图避免的 - 在理想的世界中，他会发现并且可以使用 deface 来解决这个问题..

对于不太剧烈的变化，我建议每次都使用 deface，Lavixu 提到了一个关于测试 deface 覆盖的非常好的技巧。

不幸的是，事情并没有那么简单。如果您发现自己处于这种情况，可能值得阅读上面的讨论，这非常有帮助。

于 2013-10-23T13:21:00.603 回答