Andrew Clarke

systems architect, internet developer, team leader

Andrew Clarke


The MetaData object allows you to set up custom looks and actions for the various properties of your elements.  I recommend subclassing the MetaData object and adding your own metadata in.  Here's an example subclass of a MetaData object:

component extends="ca.clarke.cfscaffold.MetaData" {

// function init()

public MetaData function init() {


local.User.list.fields.password.display = false;

local.User.list.fields.favouriteColour.display = false;

setAttribute("User", local.user);

return this;

} // init()


This tells CFScaffold that on the page that lists all the Users, don't display the "password" or "favouriteColour" columns.

See the Factory page on how to get CFScaffold to pick up your MetaData subclass instead of ca.clarke.cfscaffold.MetaData.


Each entity can have a struct with the same name set as an attribute in the MetaData.  In the example above, we created a struct for the "User" entity.  In this entity metadata struct, you can set several options:

<entity name>.<view name>.fields.<property name>.display (default true)

The view name is either "list" or "edit".  Therefore you can set the page that lists all the instances of an entity (i.e. a list of Persons), or the "edit a person" page to not display a particular property of that entity.

<entity name>.update.fields.<property name>.save (default true)

Set this to false to have CFScaffold not save a particular property when it inserts or updates that entity type.  You'll likely have to do this if you have told the edit page to hide a certain property.  For example, if you don't want a certain class of user to be able to see or edit a user's password in the "edit user" page, you'd do this:

local.User.list.fields.password.display = false;

local.User.edit.fields.password.display = false; = false;

Currently I haven't set this up to work on "view" pages yet, so if your user chooses to view a User, they will still see the password field.

Setting up CFScaffold to work within another application

CFScaffold can be run either as its own application (as in the demo), or it can be integrated into your application.  To do that, you need to set a few things.  First, you'll want the base URL to be something other than "index.cfm", as you'll want to call it from your code.  You'll also want redirections to go back to your code rather than directly to CFScaffold.  To do this, you'll set three attributes: URL_base, URL_success, and URL_failure.

URL_base is the base URL that is used for all forms and hyperlinks.  By default it's index.cfm.  You could set URL_base to something like "" if you want, and that URL will be used as the base.  CFScaffold will automatically figure out whether it needs to use & or ? to append its own query string variables.

You can also set URL_base_edit.  This lets you redirect the "edit" link to wherever you want, meaning you can use your own edit pages instead of the default one provided.

URL_success and URL_failure are the eventual locations for actions like creating, updating and deleting.  CFScaffold will relocate to URL_success if it thinks the operation was a success, and URL_failure if it thinks the operation failed.  Note that URL_failure is not yet implemented as of 2011-02-03.

One more setting you might be interested in is "useLayout".  You can set this to false if you want CFScaffold to skip the layout page and only include the actual view.  This is useful if you're including CFScaffold within your own layout, but don't want to create your own blank layout for CFScaffold.

Here's an example of how all this might come together in a page your create to drive CFScaffold from within your own application:


local.CFScaffold = application.factory.getObject("CFScaffold"); // Get CFScaffold

local.metaData = application.factory.getObject("MetaData"); // Get a metaData

local.metaData.setAttribute("URL_base", ""); // Set the base URL for CFScaffold

local.metaData.setAttribute("URL_success", ""); // Set the success URL

local.metaData.setAttribute("URL_failure", ""); // Set the failure URL

local.metaData.setAttribute("useLayout", false); // Tell CFScaffold that you don't want to use a layout.

if (structKeyExists(rc, "entityName")) local.metaData.setAttribute("entityName", rc.entityName); // Pass the entityName (i.e. Product) from rc to the metaData object

if (structKeyExists(rc, "CFScaffoldAction")) local.metaData.setAttribute("action", rc.CFScaffoldAction); // Pass the action (i.e. Edit) from rc to the metaData object.

local.CFScaffold.doAction(metaData=local.metaData, rc=rc); // Do the CFSCaffold action.  We are using rc as the object to pass to EntitySmartList instead of the default URL scope.

Also, you can see here that on the second last line, we're using rc.CFScaffoldAction as the variable name for the action instead of the default action.  This is accomplished by setting the actionVariableName variable in settings.ini.  The example above comes from an admin console I am writing that uses FW/1.


You can also set metaData attributes from within your MetaData.cfc subclass if you prefer.

1 Comment

1 response so far ↓

  • 1 Bob Chesley // Feb 2, 2011 at 5:53 AM


    Enjoyed your blog and CFScaffold looks very interesting.



Leave a Comment

Leave this field empty