culann.com

Sandstone Preview: Integration

Wow, who knew the holidays would be so counter-productive to finishing this post? Sorry about that!

Anyways, last time I gave a quick overview of the Sandstone plugin, and promised to explain the twin miracles of its customizability and upgradeability. Both of these stem from the way in which Sandstone integrates into an existing Rails application. When you install it, you get a generator - run that, and several controllers, models, and views are created in your app folder. If you open up one of the models, though, you’ll see something odd:

class Page < ActiveRecord::Base
include Sandstone::Models::Page
end


Similarly, the controllers seem… slim:

class PagesController < ApplicationController
include Sandstone::Controllers::Pages
layout 'sandstone'
before_filter :require_sandstone_editor,
:except => [:show, :destroy]
before_filter :require_sandstone_manager,
:only => [:destroy]
around_filter :authorize_sandstone_editor,
:only => [:edit, :update]
end


With both the controllers and models created by the generator, the bulk of the functionality is hidden away in modules defined within the plugin. This is the key to the whole approach - you have files in app/ that you can modify to your heart’s content - adding or overriding actions on the controllers and methods on the models as you need to, tweaking the filters and layouts used by the controllers, etc. - but the basic capabilities are preserved in vendor/plugins/sandstone. When you upgrade, then, all you have to do is install the new plugin over the old one, updating all of the Sandstone-provided functionality. Anything you’ve done in the app/ folder, however, will remain untouched (unless you rerun the generator, of course).

Obviously, this isn’t a foolproof approach. In particular, it falls down when you try to upgrade to a major release that significantly adds or changes its structure. To combat this, we’re not heavily promoting Sandstone until we get it to a point we consider stable (that’ll be Sandstone 1.0), after which we’ll keep such breaking changes to a minimum.

There is one other aspect of the integration that I’d like to talk about… Sandstone (as you can see from the controller above) has the concept of a user with a role (editor and manager, currently). Many, if not all, applications that might make use of the plugin will already have a User model of some sort, though. To deal with that, Sandstone avoids defining any sort of User model directly. Instead, it expects you to already have some sort of authentication already in place (restful_authentication or something similar, currently). The Editor model in Sandstone hooks into that preexisting model via a foreign key relationship. This allows for even easier integration into your existing system.