因此,我们希望将我们网站的一部分重新架构为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 devs,我们喜欢你的代码,但是有没有做任何工作使它成为一个真正的,真正的 Rails引擎,而不是一个独立的应用程序恰好将其所有功能打包到引擎？如果没有将它集成到现有网站的能力(包括不"拥有"应用程序,能够将所有路由分开,等等),我们就无法使用它:(
TIA.