Ruby Red Bricks

This is why I love Lego so much. You can take a toy you played with as a child and revisit it as a adult; not with a kitschy false-sentimentality, but a freshness and creative spirit that reflects that original experience.

OK, I’m waxing lyrical.. but that’s because I’ve only just come across this site:

http://www.neoclassicspace.com/

The models refer back to the old classic Space Lego, but use modern pieces and construction techniques. There’s humour in there, some lovely nods to older models – I’m particularly taken by the neat little Galaxy Explorer, a take on the 497 set I had as a kid. This mini Galaxy Explorer brings on waves of nostalgia – and of awe at the clever reworking of the old design. It’s perhaps only surpassed by the incredible Neo Classic Space ll by Peter Reid.

The original 497 Galaxy Explorer was the first big bit of Lego I ever got (or my brother got… the lines blur). It’s also the kit that got me back into Lego as an adult, when Mum and Dad put all our old toys up on a table and said “take what you want – everything else is going to charity”. Side note: my bro got all the old Hornby train sets – I think we both did OK.

I don’t expect my kids to grok any of this. In fact, after seeing what they and their cousins did to my poor old red spaceman (sorry, he just does not have blue pants.. and that skeleton head is.. kinda creepy), I would guess they’d look at these old school sets as just that.. old. Sigh.. Young people and their modular Lego kits.. in my day we didn’t have no stinkin’ movie tie-ins. But anyway, I’m sure we’re all going to have some fun with the new Space Police coming out later this year, the closest thing Lego have to the space sets of my youth.

Now, if only Lego would rerelease the old classic space sets. It’s been 30 years after all – an opportunity to cash in on the sentimentality of a bunch of old AFOLs. But it wouldn’t be the same – the past is the past. I’m as sure of this as I am that there’s always more Lego and that creativity is essentially boundless.

Part 2 of the articles on content management in Rails. This was originally written almost a year ago, when I was slightly dumber than I am now. Included for completeness, but I really want to take this in a different direction. I should pull my finger out but for now I’ll maintain the illusion of industriousness by throwing up old blog posts.

Continuing the general rant aimless musing about Rails as a CMS…

At work we use a single controller to serve up static content. The graphic designer on our team prefers to work with .html files in the file system so we use the static content controller to serve up web pages directly from disk. The files are ERB files – so ’.rhtml’ but close enough to be familiar to our designer. He also gets the bonus of all those helper methods, including custom helpers we build to make his life easier.

This approach has several advantages over keeping content in the database, like Radiant and others CMSs do. Firstly, publishing is just a matter of copying files into a known view directory. Secondly, we keep all content files under version control, so we can determine exactly which version of the content is to go live and which versions we can roll back to. We use branching to manage concurrent development of new content and maintenance of existing content.

We end up with the same model of development applying to both content and application development. The ancillary benefit is that everyone ends up talking the same language and content development ends up being managed with the same rigour that we apply to coding. This breaks down barriers in communication, allows us to work closely with designers and generally makes for a more enjoyable day’s work.

I want to use a similar approach with some documents I’m deploying as part of a web app. The documents aren’t going to change much but I don’t want to have to try to bundle them into the database using migrations. Apart from the duplication (the content would exist in both migration code and the database) I don’t want to have to build a new migration each time I make small changes to the text. Managing changes in a version control system is simpler so the static content controller approach suits here.

I also want to be to reuse this idea elsewhere, so I’m going to write the controller code as a plugin. If the code looks familiar, it’s because I nicked the original idea from here.

acts_as_static_content.rb

module ActsAsStaticContent

  def self.included(base)
    base.extend(ClassMethods)
  end 

  module ClassMethods
    def acts_as_static_content
      include ActsAsStaticContent::InstanceMethods 
    end  
  end  

  module InstanceMethods

    def static 
      #SMELL: assumes the convention app/views/foo for FooController
      if template_exists? path = "#{self.controller_name}/#{params[:id].to_s}" 
        render :template => path
      elsif template_exists? path += "#{self.controller_name}/index" 
        render :template => path
      else
        # pass through to the global error page handler
       method_missing params[:path].to_s
      end
    end

    protected 

      def each_page
        template_root = "#{RAILS_ROOT}/app/views/#{self.controller_name}" 
        excluded_actions = ['.', '..'].concat(self.hidden_actions)

        Dir.foreach(template_root) do |action|
          if !excluded_actions.include? action
            template_path = "#{template_root}/#{action}" 
            yield action, template_path
          end      
        end
      end  

  end
end    

ActionController::Base.send(:include, ActsAsStaticContent)    

The module code is introduced into controllers like any acts_as_X feature.

class MyController < ApplicationController

  acts_as_static_content

end

Any ERB files sitting in the /app/views/my folder will be available via the mixed in ‘static’ method. If we want this controller to serve up all static content by default we add this to the end of routes.rb:

map.connect '*id', :controller => 'my', :action=>'static'

Not much to it and as someone will ultimately point out you can serve up content like this with any controller methods – just drop any .rhtml file into a view folder and it behaves like an action anyway.

Putting aside any question of whether this sort of behaviour is actually desirable, the aim is to centralize the mechanism for managing content. The immediate value is in the ‘each_page’ method, as this can be used to add search features – not an explicit requirement of a CMS as per the previous post, but one my app will need and I suspect so will others.

I need to give the ‘static’ method a bit more smarts, but it’s a start. We’ve already ticked off one requirement – versioning – with a few more ready to be knocked down. This first cut will probably be unrecognizable after a few refactorings, but the only way to find out is to see what happens against a real app. So.. next post: eating my own dog food… through a straw.

Credit where it is due. The slightly tweaked brick image is from niznoz. I ran it past the four year old and it got the thumbs up – correctly identified as a Duplo™ brick.

Little side story about knowing your bricks: we often get bulk lots of Lego that have to be sorted out.. bit of fun for the whole family. One of my little darlings found a Mega Bloks™ brick, took one look and announced it as “fake Lego” – and promptly threw it in the bin. Nice to know they’re growing up with the right set of values.

This is from my old site and judging by the traffic the main reason why I get any visitors. While it possibly needs a tidy up - and it exposes some of my naivety from back then - I'm putting it up so people don't get completely cheesed off when they go hunting for the old post.

Rails is a CMS

There are now quite a few content management systems written in Rails. The chief ones would seem to be Radiant and Mephisto-as-CMS but there are dozens – of varying styles and sizes. For a quick overview there is a decent starting point. Please note: this used to be up on wiki.rubyonrails.org, but the site seems to have been trashed. The link points to a local copy retrieved from Google Cache.

The idea of using a framework on top of Rails to build CMSs has never sat right with me. I think of Rails as a kind of meta-language for describing web sites – essentially a mechanism for describing how web content is to be produced and consumed. The restrictions imposed by its architecture are easy to work with and make good sense – I’m not convinced I need to take on additional constraints and other conventions just to leverage code in an existing CMS solution.

But I could be wrong..

An idea I’m curious about: what’s the least you can do to build a working content management system using Rails? Let’s kick off by establishing what’s meant by a “content management system”. Looking back at the “starting point” wiki page there is a list of what the author considers essential features of a CMS:

• Create and edit via redcloth/etc from web
• Access control lists
• Full customization of layout and style
• Pretty urls (no /node/2235133/)
• Subpage Content items, may be referenced freely by multiple owners (graph not tree)
• Staging
• Versioning
• Lives as a component in rails, can reference content in a way similar to render_component in views
• Should produce W3C standard (x)HTML/CSS/Accessibility web site

There has to be more – and indeed there is more on the wiki page – but let’s go with that as a start and refine the spec as we go. What would we need to do to get Rails to cover these requirements without too much head messing?

Rails + Plugins = CMS

There are several plugins that seem to come almost standard these days, the acts_as_X functionality you use to deliver authorization, authentication, logging. The thing I love about Rails is that it doesn’t dictate what tools you should use – you just start with the basic framework and you add whatever you need with either your own code or what you find in gem- and plugin-land. What you use for authorization may not be what I use – though we can be pretty sure there’ll be a class called User in there somewhere that we can shape to our own evil (or good – whatever rocks your boat) ends.

The plugins model works – evident by the way that all the good CMSs end up replicating it via their own extension/plugin frameworks. But there’s a cost you have to pay taking on board someone else’s stack – someone choses a particular set of gems or plugins for example, so you’re stuck with potential incompatibilities with other code. Features are well rounded in some areas and not in others, so you miss out on stuff you want so you can have stuff you need (or need right now). A whole series of little steps and forks in the path that may lead you to commercial/personal/spiritual reward – or completely deplete you. I’m a shocker for picking the wrong horse (ask my long suffering co-workers), so I want to take on as little as possible lest anything turn out to be a dud.

It’s a question of how far you are wanting to go down the path with any vendor and it’s often a difficult exercise. Engaging with like-minded souls is extremely important, so don’t think I’m arguing against cooperation with other developers. Being involved in the open source community would have to be one of the best things to do to keep yourself honest and honed. But I am arguing for simplicity, for valuing code and for knowing what’s going on inside the systems you build. It’s a bit of journey.. so let’s push on.

Create and edit via redcloth/etc from web

RedCloth installs as a gem, as do most of ‘etc’ I imagine. Liquid Templates is another nice way to mark up your views. There’s no shortage of specialized template rendering gems/plugins in use in Rails apps – including existing CMSs.

Access control lists

What level of access do you want to manage? What other authentication technologies (LDPA, OpenID, so forth) do you need to work with? Again, there are a stack of plugins that can cover your needs here. Next..

Full customization of layout and style

Rails’ layouts and views do this out of the box.

Pretty urls

Make graves. Again, Rails does this via routes, restful resources and custom actions.

Subpage Content items

Partials?

Staging

Out of scope – set up a proper staging environment and use capistrano to manage it. And Rails does allow for multiple environments. It’s really dependent on how you run your shop, but Rails does explicitly help here so I’m giving it a tick.

Versioning

Use a version control system.

Lives as a component in rails

Crazy recursive argument brewing. Best leave that one alone.

Should produce W3C standard (x)HTML/CSS/Accessibility web site

No, you should produce standard HTML/CSS and be prepared to hand-craft the damn thing until it works on all browsers more or less the same way. It gets back to knowing what’s going on in your system. How often have you had a website not render in your preferred browser because some clown didn’t know there’s a world outside of InternetExplorer?

There are plenty of things that will make running a CMS on Rails easier. But the fundamentals don’t change between much web apps and Rails does the fundamentals well.

Managing Static Content

One thing any CMS has to do well is manage static content – by which I mean the bread and butter brochureware that makes up the bulk of the typical commercial website. Revisiting and extending our requirements:

• Content must be searchable
• Content must be versioned
• Content must be able to be staged
• Content must be easy to update

Managing static content is a central feature in a CMS. All the fancy dynamic stuff is going to live in your custom controllers and views, as it will live in the custom code of any site aiming to present a unique and/or useful user interface. Dividing the design of the CMS between features addressing frequently changing content and the relatively fixed aspects will allow me to put the dynamic parts of a CMS aside initially and concentrate on looking after the management of static content first.

The Plan

I’ve just realised I’ve said most of this before in an earlier post. Wups! Not only am I getting grumpier I’m getting forgetful. The last post sort of wandered about a bit without actually getting anywhere. I’m proposing this time around I take the outrageous step of building something that works. I’ll be borrowing some ideas from a similar system we use at work, but will be extending it along my own lines. Nothing will be particularly original – I’m not much of a coder – but I’m hoping it will be useful. And I’m kind of keen to pick up some knowledge along the way.

Next Post: The Static Content Controller

• Tags: old-stuff rails-as-cms 
• Meta: 4 comments, permalink