主题化狂欢安装；造成污损噩梦

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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 上提到过，但它们非常方便，因此强调。

Answer 3

从 Spree 用户邮件列表中的 discussion 开始，普遍的共识似乎是：

最好的选择是取消所有视图覆盖的污损 - 而这 最好通过分叉 spree-frontend 来实现。

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

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

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

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

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