Tech - October 2007 Archives

De-mystifying Content Management, Part 1

This is a post I’ve been meaning to make for a long time. However, an informal presentation of the awesome Doodlekit last night at KCRUG and a site Scotty showed me yesterday reminded of the quagmire we’re in.

The Problem

If you need to build a website for yourself or for a company, often the default answer is “You need a Content Management System (CMS)!” The problem with this assumption is multi-fold:

  1. Do we really know what it means to have a CMS?
  2. Do we know how our content will be structured?
  3. Do we know our audience and their needs?
  4. Do we have a preferred way of working? (a.k.a “workflow”)
  5. Are we managing web pages or something else entirely?

To tackle this problem, we first need to define what we mean by Content Management System, and then break it up into its varieties.

Continue reading... Wed, Oct 31, '07

Beware acts_as_list

One should be careful when using Rails' acts_as_list macro. I was reimplementing the Radiant "reorder" extension (mostly to simplify it and make it compatible with "shards") for DP when I discovered some strange problems. My reordering controller actions took this format:

def move_higher @page = Page.find(params[:id]) @page.move_higher redirect_to page_index end

But apparently, while my tests didn't show any errors in reordering things, in certain circumstances in production mode I would end up messing it up and get two items with the same position value. This would make it near-impossible to move them in any direction.

However, a member of the team had also run into the issue when using other AR macros, and the problem had to do with scoping. Of course, the Page model has the acts_as_tree macro already applied. The solution, it seems, is to (re-)load all of the models in the same scope before executing the positioning action:

def move_higher @page = Page.find(params[:id]) @page.parent.reload.children.reload @page.move_higher redirect_to page_index end

Or more tersely,

@page.parent(true).children(true)

(Incidentally, I have to use the former because I override some of those associations in other extensions.) I hope this prevents you from running into the same problem!

Thu, Oct 25, '07