大礼包作为可安装的引擎答案

【问题标题】：Spree as a mountable engine大礼包作为可安装的引擎
【发布时间】：2011-12-20 22:19:40
【问题描述】：

因此，我们希望将网站的一部分重新架构为 Rails 应用程序。最初的计划是拥有一个主要的“站点”应用程序，其中包含许多具有分隔功能的插件应用程序（Rails 3.1 引擎）——一个商店组件、一个社交/论坛/聊天组件等。此外，我们想要放置主题/styling 在 gem 中，以便我们的网页设计师可以修改网站外观和一些小的布局调整，而无需“了解 Rails”。最初，这进展顺利。我们创建了主要的架构和插件以及主题 gem，所有这些都很好地结合在一起；像身份验证这样的横切功能被放置在主“站点”应用程序中，并且可以由插件应用程序使用，从而为我们提供了站点的单点登录（设计要求）。

我们对商店组件的最初计划是使用 Spree (http://spreecommerce.com/)，因为它具有开箱即用的 95% 以上我们需要的功能。然而，有一个问题——Spree 是作为可安装引擎分发的，但它也是一个应用程序。这意味着 Spree 不仅会安装在应用程序中（这不是问题，实际上这是我们所依赖的行为），而且它取决于对主应用程序的控制。调查这种行为的“原因”，它似乎取决于两个核心功能。第一个功能块是一些必须进入中间件的 SEO 永久链接重写功能；我们可以破解一些东西，以便我们的主应用程序包含这段代码（尽管这会开始在我们整个网站上纠缠存储功能，混淆“作为可安装引擎的 Spree”的故事......稍后会详细介绍）。

更复杂的是 Spree 使用 Deface 进行主题化和自定义。虽然这很“聪明”（注意引号），但它确实让 Spree 的整合成为一场噩梦。要么你走阻力最小的道路，让 Spree 成为一个独立的商店（这完全打破了我们关于“商店只是我们网站的一部分，并且与网站的其余部分，包括身份验证、主题等）相得益彰的故事.")，否则你必须彻底摆脱 Spree。

不仅如此，Spree 还没有遵循标准的 Rails 引擎路由范例，其中路由被隔离在引擎根下（如果您查看 lib 的 routes.rb 文件，您可以看到它使用 Rails.Application 的路由，而不是引擎的路线）。这意味着我们不能拥有 www.oursite.com/store/...all_the_spree_goodness，我们必须拥有 www.oursite.com/spree_owns_the_sites_routes...

那么，有其他人尝试过吗？我们喜欢 Spree，并希望将其用作我们的商店。但它开始看起来没有真正的方法可以将它与我们网站的其他部分“集成”，除了可能使用 nginx 或类似的代理魔法（这是一个单独的噩梦，因为我们希望在 Heroku 上托管，然后我们必须弄清楚如何将多个不同的应用程序集成到一个数据库中——用于单点登录身份验证——以及一个 HTTP 前端路由器）。

Spree 开发人员，我们喜欢您的代码，但是是否有任何工作可以使其成为真正的、真正的 Rails 引擎，而不是碰巧打包的独立应用程序它的所有功能都融入了引擎？如果无法将其集成到现有网站中（包括不“拥有”应用程序、能够将其所有路由分区等等），我们就无法使用它:(

TIA。

【问题讨论】：

在阅读下面 Ryan 的回复后，我认为我的问题归结为两个子问题： 1. 我怎样才能将 Spree 用作真正的可挂载引擎？答：使用更高版本；在安装 edge Spree (1.0.0.beta) 之后，我希望的所有引擎优点（尤其是容易隔离的子路由）似乎都“正常工作”。 2. 我讨厌污点！（好吧，这不是问题 :) 情况仍然如此，但我想我可以覆盖视图并按照现有的每本 Rails 书籍演示的方式自定义它们，而不是为 everything。所以，我们会尝试一下。

标签： ruby-on-rails spree rails-engines

【解决方案1】：

我是 Spree 的社区经理，所以我想我可以回答你的问题。

是的，我们正在努力让 Spree 成为真正的 Rails 引擎。事实上，这是我在被 Spree 聘用时所做的第一个任务。这项工作在 master 分支 (https://github.com/spree/spree) 上，我们希望在圣诞节前后将此代码作为 1.0.0.rc 发布。

使用此代码进行了一些更改。对于初学者来说，Spree 现在是一个合适的 Rails 引擎，这意味着您现在可以将它安装在 /spree 或 /shop 或 /whatever 上，Spree 很酷。其次，所有模型和其他类都是命名空间的，因此它们不会与您的应用程序中的任何内容发生冲突。

不过，我不确定你所说的 Deface 是“聪明”是什么意思。你认为这会带来什么问题？如果你想覆盖整个视图，你可以通过覆盖app/views/spree/products/show.html.erb 中的路径来实现。请注意，这会覆盖整个视图，如果您只想覆盖其中的一部分，那么您应该使用 Deface。

您能否详细说明您在使用 Deface 时遇到的问题？有兴趣帮助您解决这些问题。

感谢您使用 Spree！

【讨论】：

感谢您的回复，瑞恩。我对 Deface 感到沮丧，所以我在公共场合有点吝啬。在我看来，在 Spree 中，Deface 几乎完全用于自定义视图，我认为这是一个奇怪的选择。诚然，如果您只想更改徽标或背景颜色，也许 Deface 是一个轻量级的解决方案。但我敢打赌，大多数商店都希望从根本上重写视图以匹配他们自己的公司外观和感觉（谁想要一个千篇一律的商店，对吧？），当你达到这种定制水平时，Deface 变得更加与其说是帮助，不如说是阻碍。
我们有一个完整的设计团队来为我们制作视图和样式，所以 Deface 不太适合 - 它似乎来自您将使用基本的期望按照给定的视图骨架，只需使用 Deface 对其进行“调整”，如果您不想以这种方式构建视图，那么它是一个相当重的依赖项。所以，这是我对 Spree 的两个问题——它不想在另一个应用程序中很好地发挥这一事实是阻碍，但 Deface 是额外摩擦的来源。
您可以从 spree 的各个部分复制视图并将它们放在应用程序中的确切路径中。 Rails 将在您的应用程序中搜索视图，然后再返回查看引擎。
感谢您的帮助，瑞恩。我现在正在定制 Spree，将其身份验证与现有应用程序集成以提供单点登录功能。现在我可以将它安装在另一个应用程序中（具有自己的命名路径），并且可以绕过 Deface，我是一个快乐的露营者。
很高兴听到 Tom :) 如果您有任何其他问题，请告诉我们。