ruby-on-rails - 为 Spree 安装设置主题；造成污损噩梦

Question

首先在 Programmers.SE 上键入此内容，但想象一下这可能更适合这里 - 纯粹是因为它不征求有关特定技术问题的建议。不过，请随意投票以采取行动!

我目前正在使用 Ruby on Rails 的 “Spree” 电子商务平台开展一个项目。配置和使用它是一种完全的乐趣。快乐就此停止。

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

1. 使用deface 覆盖。到处。似乎要覆盖其他覆盖。
2. 完全重建 View 。

自然地，对于风格的如此巨大的改变，使用污损是一场彻头彻尾的噩梦； Deface 看起来不像是可以接受的重写完整 UI 的方式；它似乎也不是很有效。所以我选择完全重建 View 。

然后意识到大约有 8 个插件都依赖于破坏覆盖， View 文件是硬编码的，目标选择器通常是“flakey”(充其量)。

除了极小的 documentation在 spree 网站上，我所能找到的只是各种 session 的幻灯片，如果没有谈话的背景，这些幻灯片实际上用处很小。他们似乎都专注于使用污损覆盖来进行基本简单的更改，而最近的更改似乎已有一年多了。

我错过了什么吗？有谁知道执行此类操作的最佳做​​法？我实际上应该看哪里？

Answer 1

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

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

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

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