4

So, we want to rearchitect a portion of our site as a Rails app. The original plan was to have a main "site" app, with a number of plugin apps (Rails 3.1 Engines) with compartmentalized functionality -- a store component, a social/forums/chat component, etc. Also, we wanted to put themes/styling in a gem so that our web designers could modify the site appearance and some minor layout tweaks without having to "know Rails." Initially, this was going well; we created the main architecture and plugins and the theme gem, and it was all playing nicely together; cross-cutting functionality like auth was put in the main "site" app and was consumable by the plugin apps, giving us a single sign-in for the site (a design requirement).

Our initial plan for the store component was to use the Spree (http://spreecommerce.com/) since it had, out of the box, 95% plus of the functionality we needed. However, there's a catch -- Spree is distributed as a mountable engine, but it's also an app. Meaning that not only does Spree mount inside an app (which is not a problem, in fact it's behavior we were counting on), but it depends upon being in control of the main app. Looking into the "why" for this behavior, it seems to depend upon two core pieces of functionality. The first chunk of functionality is some SEO permalink rewrite functionality that has to go into middleware; we could hack things so that our main app included this chunk of code (even though this would begin to entangle store functionality across our entire site, muddying the "Spree as a mountable engine" story... more on that in a moment).

More complicated is Spree's use of Deface to do theming and customization. While this is "clever" (note quotes), it really makes the integration of Spree kind of a nightmare; either you follow the path of least resistance and make Spree an entire store to itself (which completely breaks our story of "the store is just one part of our site, and plays nice with the rest of the site, including auth, theming, etc."), or you have to hack the hell out of Spree.

Not only that, but Spree doesn't follow the standard Rails Engine routing paradigm, where routes are isolated beneath an engine root (if you look in the lib's routes.rb file, you can see that it uses Rails.Application's routes, instead of an Engine's routes). This means that we couldn't have www.oursite.com/store/...all_the_spree_goodness, we'd have to have www.oursite.com/spree_owns_the_sites_routes...

So, has anyone else tried this? We LOVE Spree and would like to use it as our store. But it's starting to look that there's no real way to "integrate" it with the rest of our site aside from maybe some proxying magic with nginx or something like that (which is a separate nightmare, since we're hoping to host on Heroku, and then we have to figure out how to integrate multiple disparate apps into one DB -- for single sign-in auth -- and an HTTP front router).

Spree devs, we LOVE your code, but is there any work being done to make it an actual, for-real Rails Engine, as opposed to a stand-alone app that just happens to package all of its features into Engines? Without the ability to integrate it into an existing site (including not "owning" the app, being able to have all of its routes partitioned off, and so on), there's just no way we can use it :(

TIA.

Tom Canham
  • 71
  • 2
  • After reading Ryan's reply below, I think that my question boils down to two sub-questions: 1. How can I use Spree as a true mountable engine? Answer: use a later version; after installing edge Spree (1.0.0.beta), it appears that all the Engine goodness I was hoping for (esp. easily isolatable sub-routes) "just works." 2. I hate Deface! (Okay, this isn't a question :) This is still the case, but I guess that I can just override the views and customize them the way every Rails book in existence demonstrates instead of fighting with Deface overrides for *everything*. So, we'll try that. – Tom Canham Dec 22 '11 at 20:56

1 Answers1

6

I'm the Community Manager for Spree, so I think I may be able to answer your question.

Yes, there is work going on that will allow Spree to be a true Rails engine. In fact, that was my first task that I did when I was hired by Spree. The work is on the master branch (https://github.com/spree/spree) and we're looking to release this code as a 1.0.0.rc around Christmas time.

With this code, a couple of changes have been made. For starters, Spree is now a proper Rails engine meaning that you can now have it mounted at /spree or /shop or /whatever and Spree's cool with that. Secondly, all the models and other classes are namespaced so they won't conflict with anything in your application.

I'm not sure what you mean about Deface being "clever", though. What problems do you forsee with this? If you want to override an entire view you could do this by overriding the path in app/views/spree/products/show.html.erb. Mind you, this overrides the whole view, and if you only want to override a part of it that's when you'd use Deface.

Could you perhaps elaborate on the issues you're having with Deface? Would be interested to help you sort them out.

Thanks for using Spree!

Ryan Bigg
  • 106,965
  • 23
  • 235
  • 261
  • Thanks for responding, Ryan. I was frustrated at Deface, so I was kvetching a bit in public. It seems to me that in Spree, Deface is used almost entirely for view customizing, and I believe it's an odd choice. True, if you only want to change the logo or a background color, maybe Deface is a lightweight solution. But I would wager that most stores will want to essentially rewrite the views to match their own corporate look and feel (who wants a cookie-cutter store, right?), and when you're getting to this level of customization, Deface becomes more of a hindrance than a help. – Tom Canham Dec 22 '11 at 16:54
  • We have an entire design team to make views and styles for us, so Deface just isn't a good fit -- it seems to be coming from the expectation that you're going to use the basic view skeleton as given, and just "tweak" it with Deface, and if you don't want to build your views this way, it's a fairly heavy dependency to carry. So, these were my two problems with Spree -- the fact that it doesn't want to play nicely in another app is the blocker, but Deface was a source of extra friction. – Tom Canham Dec 22 '11 at 17:01
  • You can copy over the views from the parts of spree and put them at the exact paths within your application. Rails will search in your application for the views before falling back to looking into the engines. – Ryan Bigg Dec 23 '11 at 01:19
  • Thanks for your help, Ryan. I'm on my way customizing Spree now, integrating its authentication with an existing app to provide single sign-on capability. Now that I can mount it in another app (with its own namespaced routes), and I can bypass Deface, I'm a happy camper. – Tom Canham Dec 29 '11 at 17:12
  • Great to hear Tom :) If you have any other issues please let us know. – Ryan Bigg Dec 30 '11 at 00:39