How the CF community should engineer a scaffolding replacement
posted under category: General on March 17, 2006 by Nathan
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.
[Pre-Generate]
We need to pre-generate forms give the flexibility to modify. Forms dynamically created on request would not be so easily customizable.
[Oh CRUD]
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.
[Templating]
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...
[Validation]
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.
[Administration]
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-Generate]
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!