The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

How the CF community should engineer a scaffolding replacement

posted under category: General on March 17, 2006 at 1:00 am by MrNate

This is me scratching down some notes for my theoretical scaffolding project, a mechanism that takes a database model and turns it into a set of forms and records pages.

We need to pre-generate forms give the flexibility to modify. Forms dynamically created on request would not be so easily customizable.

Do we marry the scaffolding framework to an ORM such as Reactor, or do we have it create the necessary DAOs itself? In the effort of not duplicating any work that has already been done, and to not render any pre-installed data access layer useless. Our project should have tie-ins to the various ORM frameworks and require that one exists. It should, however be possible to extend the framework to use any custom data model layers, and to force it to manually map to a cfc/function. To summarize - this tool is not a SQL generator - there are plenty of those elsewhere.

[Reading Fields]
Where does the data come from? If we are going to force the use of an ORM like Reactor or ARF, we may be able to read metadata out of those objects. It would be safer than reading it out of the database, in case the ORM uses aliases to certain tables. Creating autowiring to all of the major ORMs has a huge possible headache factor.

The product should ship with a few templates, Flash forms, plain CFForms, plain HTML forms, etc, a few of each. Each template should probably contain named field templates. The idea here is the rendered template is as close to a form that you actually want to use as possible. The less modifying on the end-result, the better.

Furthermore, the item list page should have a few templates to choose from to complete the round-trip process. Again, we should include a few with the framework.

More after the jump...

We need to make a way to include the most popular form validation techniques, be it qForms, cfform default validation, custom server-side validation, validation based on the ORM, or any combination of the above. The template page will control where validation messages appear (if inline).

[Table Metadata]
We all have (or should have) metadata on most of our tables - who created this and when, is it deleted, etc. You don't want that info printed out on the form, and you shouldn't have to delete it from the generated code every time you make a form. This would be a fairly simple system of checking which fields shouldnt' show up.

An attractive, easy-on-the-eyes administrator to manage everything on a global level, manage the generation of 'scaffolds', manage a scaffold on an individual level, and manage each and every form field, including displaying, default values, linking selects, form field types, etc. Yes, this is very granular. You will have to drill down a ways to find these details, but if we don't put it in, nobody will be happy.

[Client Ready]
Imagine if we had a client-ready, somewhat dumbed-down interface. Your CMS users could make their own forms based on a generic table. This may be a side-project, but a useful one, nonetheless.

Re-generating a scaffold shouldn't overrwrite everything if any changes have been made to it. We should consider partial regeneration where possible.

[Rediculously Easy]
It needs be easy to set up and create the first few forms. Easy as dropping the files in a folder and hitting it in your browser. Perhaps a quick setup page and a tour mode that turns on helpful tips for your first few times through. We have to tout the real WOW factor.

[Recognize Changes]
Something I know Reactor does, if a table changes, it modifies all the CFCs it has created for said table. New fields should be added instantly to forms.

[Special Data Rules]
Everybody's database has special rules. For instance, deleting a record sometimes means changing a deleted bit flag. This change has to be reflected on the item list. Changes of this sort should be considered and many will likely be adapted as an administrative option.

[Framework integration]
Many developers using this product need framework support. As such, framework code needs to be generated and inserted into the correct and logical place. Of course, options would exist to prevent tampering with your configuration files. In these cases, developers should be presented with framework-specific code that they can insert into their files manually.

[Framework reliance]
To Be Determined. The administration tools should be built to harness a framework, and use of frameworks should be implicitly preferred wherever we go. I have no preferences, personally. I may like to stick it in model-glue just for giggles (thanks Ray Camden).

I have a feeling I'm biting off more than anyone can chew. This stuff is totally open for public ridicule/flames/corrections/additions/praises. Leave comments!

Too old to comment!
On Mar 17, 2006 at 1:00 AM Mark Fuqua (mark who hates said:
I know it is not OO, but look at how PLUM does this through the use of it's IDE and databaseBlocks.cfc.

It is pretty cool.


On Mar 17, 2006 at 1:00 AM Pete Freitag ( said:
I'm looking forward to seeing what you come up with!

On Mar 17, 2006 at 1:00 AM Nathan Strutz ( said:
What? I thought you were doing it. Nah, in all reality, I'm looking forward to seeing if I can come up with anything useful.

On Mar 17, 2006 at 1:00 AM Pete Freitag ( said:
Haha, yeah this type of project is high on my list of "things to do if I had time to do them"!

On Mar 17, 2006 at 1:00 AM Ryan Guill ( or said:
Wow, lots of great thoughts! But first thing you need to do is come up with an awesome, web-2.0 type name. CF on train tracks anyone? ;)

Seriously though, looks like you definately have things thought out pretty well.

On Mar 17, 2006 at 1:00 AM Rob Cameron ( said:
ColdFusion on Wheels should have scaffolding in the next couple months! I don't think it'll be nearly as feature-rich as what you're describing, though. Wheels will be more (of course) Ruby-on-Rails-like in that it gives you a set of pages to work with a table in the database: list, new, edit, delete.

This would be, of course, pretty tightly integrated with the framework. It would be generating the controllers and views necessary to access the model representation of the database (which is ActiveRecord-like). But yeah, it would let you get an ultra-basic site up in a few seconds.

On Mar 17, 2006 at 1:00 AM Mike Kelp (mike.kelp, who eats said:
Why don't we make an interface for scaffolding.

For instance, make an object that receives an XML, struct, or some pre-defined format for describing what database columns, types, etc. are needed in the form and any other information that needs to be given to the scaffolder.

Then have some set functions that a framework or app can call (without worrying about the code that is generated or the type of generator being used).

This way, you can provide a simple API for making a form builder that conforms to any person's standard. If they don't like yours, they can implement their own using the api and drop it in (no changing any other code to get it working).

The goal in my opinion should be to have a nice front end (like what CF On Wheels has) that could be used to generate a form that conforms to any framework or any format. Then you could actually have a choice between building a flash form or html form, or a Mach-ii or Model Glue Scaffold.

On Mar 17, 2006 at 1:00 AM Nathan Strutz ( said:
That, my friend, is the beauty of collaboration. Great suggestion, I'll put some more thought into it!

The interface idea... Hey, you just turned my 6-year project into 15 minutes :D woohoo! Nah, just kidding. That would sort of transform the project into more of a plugin-based framework. I like it, I really do.

Rob - Come on, dude, blog it! If you don't, I may just start blogging people's comments ;) - Great job, BTW, I really look forward to it.
Too old to comment!