因此，我们希望将我们网站的一部分重新架构为Rails应用。最初的计划是拥有一个主要的“站点”应用程序，其中包含许多具有分隔功能的插件应用程序（Rails 3.1引擎） - 商店组件，社交/论坛/聊天组件等。另外，我们想要放置主题/在宝石中设计风格，以便我们的网页设计师可以修改网站外观和一些小的布局调整，而无需“知道Rails”。最初，这进展顺利;我们创建了主要的架构和插件以及主题gem，它们一起玩得很好;像auth这样的横切功能被置于主“站点”应用程序中，并且可以被插件应用程序使用，为我们提供了网站的单点登录（设计要求）。
我们对商店组件的初步计划是使用Spree（http://spreecommerce.com/），因为它具有开箱即用的95％以上的功能。然而，有一个问题 - Spree作为可安装的引擎发布，但它也是一个应用程序。这意味着Spree不仅会在应用程序中安装（这不是问题，实际上它是我们所依赖的行为），但取决于控制主应用程序。研究这种行为的“原因”，似乎取决于两个核心功能。第一块功能是一些SEO永久链接重写功能，必须进入中间件;我们可以破解东西，以便我们的主要应用程序包含这一大块代码（尽管这将开始纠缠整个网站的商店功能，将“Spree作为可安装引擎”的故事混淆......稍后详细介绍）。
更复杂的是Spree使用Deface进行主题化和自定义。虽然这是“聪明”（注意引用），但它确实使Spree整合成了一场噩梦;要么你遵循阻力最小的路径，要让Spree成为一个完整的商店（这完全打破了我们的故事“商店只是我们网站的一部分，并与网站的其他部分，包括auth，主题等等相得益彰。），或者你必须破解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。
答案 0 :(得分：6)
我是Spree的社区经理，所以我想我可以回答你的问题。
是的，正在进行的工作将使Spree成为真正的Rails引擎。事实上，这是我在施普雷聘用时所做的第一项任务。工作在master分支（https://github.com/spree/spree）上，我们希望在圣诞节期间将此代码发布为1.0.0.rc。
使用此代码，已进行了一些更改。对于初学者来说，Spree现在是一个合适的Rails引擎，这意味着你现在可以将它安装在/ spree或/ shop或/的任何地方，并且Spree很酷。其次，所有模型和其他类都是命名空间，因此它们不会与应用程序中的任何内容冲突。
我不确定你对Deface的“聪明”是什么意思。你有什么问题吗？如果要覆盖整个视图，可以通过覆盖app/views/spree/products/show.html.erb中的路径来完成此操作。请注意，这会覆盖整个视图，如果您只想覆盖当使用Deface时的部分内容。
您是否可以详细说明您在使用Deface时遇到的问题？有兴趣帮助你解决它们。
感谢您使用Spree！