» tagged pages
» logout

(Feed found, click Add Page to syndicate.) Error finding feed, please try again » Find feed title

A Blog Page allows you to add entries, for news or other time sensitive postings

(Login required to save to your tagged pages.)
(or Cancel)

Make further edits, (or Cancel)

(Login required to save to your tagged pages.)
(or Cancel)

(Editing anonymously: to be credited for your changes, login or register a new account)

Change Page Permissions? Changing these permissions will adjust who can modify this page.

Anonymous (change)
Swik Users (change)
(or Cancel)
Upload an image from your computer:
or Copy an image from a URL:
or Erase the current icon:
Icon Preview:

or Cancel

Erase scaffolding? The contents of scaffolding page and all pages directly attached to scaffolding will be erased.

or Cancel

(Editing anonymously: to be credited for your changes, login or register a new account)

other page actions:
scaffolding

scaffolding

Tags Applied to scaffolding

No one has tagged this page.

scaffolding Wiki Pages

sorted by: recent | see : popular
Content Tagged scaffolding

Scaffolding's place

Scaffolding, scaffolding, scaffolding… In a recent article I said that “I have lots of issues with scaffolding”. Why would that be? I mean, what’s not to like about scaffolding, really? It’s all about rapid application development, and prototyping, and getting real, isn’t it? Isn’t it?? WELL????

Specifically, the issue I have with scaffolding is this: it puts the emphasis on the application’s model, instead of the user interface. It assumes that you know the domain of the application before you know how the user is going to interact with it. It assumes that the user interface can successfully follow your conjured domain. It assumes, frankly, far too much.

Now, don’t get me wrong: as a pedagogical aid, scaffolding is great. It lets newcomers to Rails quickly get a skeletal app up and running, giving them a platform from which to beginning learning Rails without stumbling over too many details. That’s great. But scaffolding is not for building real applications.

Your users don’t care about the data model. Face it, they just don’t care. They will never interact with the data model. They will never interact with your carefully crafted schema. They interact with the UI. Therefore, it is very important that when you start an application, you start with what the users will care about. Get the UI right. Sketch it out, mock it up, get it real. Once you have a “real” UI to work from, it is amazing how much it can tell you about the application’s domain.

A single screen can tell you more about what models you need and the relationships between them than a hundred-page written specification. A picture really is worth a thousand words. And the remarkable thing is this: the model you infer from the UI is often not what you would have created had you gone for the model first.

Furthermore, working with scaffolding makes it nigh impossible to do test-driven development, whereas working from a UI makes it very, very easy. With scaffolding, what tests would you write first? What is the behavior your want your final product to have? That’s not a very easy question to answer when all you know is the set of models you think your application needs.

When working from a UI, though, you can look at all the elements and data on the page and immediately start seeing what tests you need. “If the user is an administrator and they view the page, they ought to see this link, but otherwise that link is hidden.” BAM, instant test case. And you immediately know you’re going to need (at the very least) “users”, some of whom can be “administrators”.

I’ll say it again, scaffolding is a great learning tool, like training wheels or parachuting in tandem with an instructor. But when you do the real thing, those training wheels come off. You jump from the plane alone. You design the UI first.

Capistrano: the { buckblogs :here } - Home

Username:
Password:
(or Cancel)