Spree Commerce

Try It Now

The Road to Rails 3 - resource_controller

Posted on June 15, 2010 by Brian Quinn

There’s been lots of discussion recently on spree-user and at the Spree BOF at RailsConf regarding Spree’s use of resource_controller (r_c), and our options as we move towards Rails 3. We’re confident that our migration to Rails 3 is going to be a great step forward for the platform, as it will greatly simplify how Spree implements extensions due to the fantastic engine and railtie features in Rails 3. Some members of the community have suggested that we use the Rails 3 migration to also remove r_c from Spree. We’ve seriously considered this and I’d like to explain how we’ve arrived at our decision to keep resource_controller.

Issue 1: Removing resource_controller will simplify controller code and make it more understandable especially to new developers:
This is probably one of the most compelling reasons to remove r_c as we accept that the learning curve for the controller logic can be a little steeper than a traditional rails application. Some controllers especially the checkouts controller would benefit greatly by removing r_c code as it’s not a true restful resource and not a good candidate for r_c use. In the future we plan to ensure all unsuitable controllers will be rewritten to reduce the usage of r
c and improve readability and maintainability, starting with the checkouts

Issue 2: resource_controller isn’t actively maintained and not currently Rails 3 compatible.
While r_c hasn’t been getting much attention from it’s original author (James Golick) it does have a large network of forks and it still receiving frequent improvements / bug fixes. We’ve spent a considerable amount of time migrating r
c to Rails 3 and we’re happy to say that it’s now fully functional and we’re also very close to getting all tests passing after some badly needed attention at RailsConf / BohConf (thank you Derek). Please take a look at our http://github.com/bdq/resource
controller and patches / comments are welcome.

Issue 3: inherited_resources is a better alternative:
After some review we’ve found that inherited_resources is not missing many of the features that resource_controller offers, it does however implement them in a significantly different way which would add considerable overhead for any migration (as core and all extensions would need to be-written to match). There are two key features provided by resource_controller that differ in inherited_resources:

  • In-action before and after filters that unlike standard Rails filters get executed just before / after the actual event takes place, when the object has already been loaded / built. This allows extensions and core Spree to cleanly and efficiently hook into actions without adding lots of unnecessary database activity that’s normally associated with traditional before / after filters. r_c also supports filters based on the result of a particular action (success / failure), and they’re also stack-able allowing core and multiple extensions to add multiple callbacks to a single filter.  
  • Render / redirect overrides allows developers to simply change what gets rendered or where an action will redirect a user after completion in both success and failure states.

Both of the these r_c features enable developers to add / replace small pieces of logic without overriding and replacing entire controller actions which greatly eases version upgrades, and provides a unique pluggable architecture for Spree extensions. Re-implementing these features using inherited_resources would be very time consuming and counter-productive at this point in time.

Code bloat

During one of our BohConf hacking sessions we decided to rewrite a single controller (admin zones_controller) removing r_c while still retaining all the hooks / extensibility features mentioned in issue 3. This exercise allowed us to evaluate what the codebase might look like after the removal of r_c. We did expect the code to grow a small amount but we were surprised that it actually ballooned from 35 lines to 105 lines after the change. While readability and simplicity did improve, DRYness and maintainability suffered greatly. The overall consensus on this point was that the DRYness / maintainability benefits far out weights any simplifications gained.


After reviewing both options of either removing resource_controller completely or switching to inherited_resources it’s become clear that a lot of the customization that Spree offers is deeply linked to resource_controller functionality. While inherited_resources is a promising option it currently poses too much of an overhead in terms of rewriting coding and changes to the overall internal workings of Spree.      

Overall we think that resource_controller adds a lot of value to Spree and that any plans to remove it would damage Spree’s well known and loved extensibility.

Spree 0.11.0 Released

Posted on June 14, 2010 by Sean Schofield

Spree 0.11.0 has been officially released. This release makes Spree compatible with the latest Rails 2.3.8 release. Several changes to Spree were required to get this to work (especially without deprecation warnings.) The impact on existing 0.10.x stores should, however, be minimal. As always, it is suggested that you perform a complete backup of your database and system assets before upgrading.

The new release contains a change to the default Spree theme to match the new logo. Nothing drastic – just a slightly different color scheme to go better with the new logo colors. There aren’t any real major features in this release but there are a ton of ton of important bug fixes and other changes. The Github compare for this release shows 173 commits by 20 different authors. So thanks once again to all of the people in the community that are working to improve Spree.

New Look for Spree

Posted on June 07, 2010 by Sean Schofield

Today we are pleased to announce the launch of the newly designed Spree site. We’ve been hard at work on this site while simultaneously working our days jobs taking care of our Spree clients. The most important new feature of the site is the ability to register your own company and then register websites for the showcase. We’re moderating new companies and sites so please allow a few hours before expecting to see your company/site listed. This is an unfortunate step needed to prevent spammers from ruining the site. We’re going to be adding more functionality and instructions to the registration process but we wanted to make sure that we launched the site in time for Rails Conf.

You will probably also notice that we have a brand new logo! The old logo was a bit generic so we were looking for something a little more unique to capture the spirit of the Spree project. Personally I think it captures the deceptively simple nature of the Spree project. The mission of the Spree project is to write the best e-commerce software out there and to have some fun and make our customers happy in the process. I think the logo captures this sentiment perfectly.

Site credits: Elevate with Rails Dog

Logo credit: Dynamo

Spree Roadmap (May 2010)

Posted on May 04, 2010 by Sean Schofield

We’ve been hard at work on some client projects lately but we’ve also been quietly improving the Spree code with minor patches. Lately we’ve had a lot of people asking about Rails 3 support and other topics regarding the future direction of Spree. I thought I would take a few minutes to outline where the project is headed over the next few months.

Rails 3 Support

The most important development coming to Spree is support for the new Rails 3 release. Spree has always been quick to support new versions of Rails and we plan to continue to keep pace with the fast moving pace of the Rails core team. The newest version of Rails will offer several improvements that will reduce the amount of hacks needed to get Spree working on top of Rails. The upgrade to Rails 3 will yield several benefits.

  • Easier integration with Rails apps
  • Elimination of the site extension – all custom code can reside in RAILS_ROOT
  • Extensions as engines
  • Extensions as gems
  • More modular design which will allow developers to use only select modules (similar to Rails)
  • Faster performance in development mode
  • Less code to maintain in the Spree project

The core team has already started to explore the implications of a Rails 3 upgrade. We’re conducting several experiments to test the new functionality which is still in beta and not well documented. Our initial results are encouraging and we’re going to be starting a massive development push on this in May. Our goal is to have Rails 3 support in time for Railsconf.

More Core Members

We’re hoping to add more core team members to the project – ideally from companies other than Rails Dog. The heavy Rails Dog representation on the core team is a byproduct of needing to hire the best Spree developers we could find. All of the core members now on Rails Dog started out as independent contractors.

We’re definitely interested in broadening the representation on the core team. We could certainly use more help with keeping on top of the patches and tests needed for our fast moving code base. Last year we posted something on how we choose core team members if you’re interested.

New and Improved Showcase

The current list of Spree sites is woefully out of date. We’re working on a much improved showcase that will allow members of the community to share their sites with the rest of us. New entries will be moderated and we’ll also have the option of a "private listing" which allows you to register the site but not to share it with the public. We prefer that you share your site with everyone, but if your client is uncomfortable, you can at least share it with the core team. You’ll also receive credit for listing a private site when it comes to your ranking in the new Developer Listing section of the website.

Developer Listing

The Spree website is currently undergoing a major overhaul. In addition to some visual and organizational improvements, there will new sections such as the "Developer Listing." This section of the website will list development shops who are currently building Spree sites. We’ll be giving priority to those companies/freelancers who have built the most verified Spree sites. It will also be possible to browse the public sites and extensions contributed by each of the companies/individuals in the developer listing.

Improved Documentation

The documentation is in need of some major refactoring. We’ve been pretty good about keeping the documentation up to date but it needs to be reorganized along some more useful guidelines. In general, we’d like to see documentation split out into information that is useful for setup/configuration and that which is useful for customization/development. We’re going to try and separate out some of the low level technical detail so its easier to focus on getting up and running. We’ll still have the technical details but in a section that is more geared towards developers.

Full Featured Demo

We’re very interested in building a more full-featured demo of Spree. The idea is to go beyond the basic store that comes "out of the box" and show potential users something a little more sophisticated. The Spree core is not going to contain support for Google Checkout, full text search, Paypal Express, etc. but we want to show that this is easily done with extensions. The idea is to make this open source version of the demo available to everyone so it can also be used as the starting point for a store or simply as a means to study the Spree extension mechanism more closely. We don’t have an estimated timeframe for completion of this demo. Most likely it will be in the Fall of 2010.

Spree 1.0

Finally, the Spree project will hit "1.0" status sometime this year. This is mostly a symbolic milestone but its an important one. Once we reach 1.0 status we will be much more hesitant to change anything that will break existing sites and extensions. We still try to minimize this type of change now but sometimes its justified in order to significantly improve the core based on valuable insight we have gained from our users and real world deployments. The 1.0 release will take place after the Rails 3 support is released and all of the important extensions have been upgraded.