What is Scaffolding and how do I use it? - Part 2

So you want to use an architecture to avoid those nightmares. Unfortunately its not easy to get started. Unlike building a single page web site you have to create a lot of stuff before you even see anything. In Fusebox 5.1 with MVC you have to create a view directory with a dsp_ fuse, a controller directory with a circuit.xml, in the root goes a fusebox.xml and you define your application name in index.cfm before you get close to seeing the magic words "Hello World". If the words are going to come from a database you have to create a model directory and a qry_ fuse too.

So what if your application does more than output "Hello World"?

It gets even more complex when the application starts to use more tables. Each table probably represents an object in the object model. You might end up creating CFCs to act as a Bean, DAO, Gateway, Service and Transfer Object for each table.

Maybe your application uses 20 tables? That's already 100 CFCs to write!

Each table will need several fuseactions to make it work. I usually end up with about seven per table. That's 140 fuseactions.

The worst thing about all that its that its a lot of typing. And its boring typing too! Quite repetitive and tedious.

This is where the scaffolder will help. It will do lots of typing for you. The scaffolder creates scaffolding. The scaffolding will help you construct your application. You might even think of it as a foundation for your application.

Depending on the chosen set of templates it will generate more or less all of the model CFCs and some of the dsp_ fuses too. So they may not be exactly what you want but modifying what the scaffolder creates is a lot easier than typing it all in the first place. In addition the scaffolder has built into it a model of what best practice is for the style of application you are creating. So it puts all the files in the right place. If you don't like where it puts the files just change it. There is documentation showing how to modify the template descriptor file which controls where all the templates get placed.

"What do I need to do?" I hear you ask.

The first thing you should do is design your database. If you have any influence at all over the database design make sure it is accurate and make sure it reflects your requirements. Any time spent getting this right will pay off later.

Once the database is as good as you can make it run the scaffolder. In the Alpha version that means copying four lines of code into your index.cfm file. Later it will be simply adding a URL parameter.

I usually add another line here to stop the generated fusebox application actually executing at this stage since it is unlikely to be exactly right at this point.

At this point you might take a peek at the generated code. "Wow!" I hear you say, "What's all that stuff?" Hang on a minute before you get into all that check that the XML in the scaffolding xml page has all the table relationships that it needs. Your database may not be complete in terms of having all the relationships defined. In my experience many don't, often for reasons of performance.

So at this point add any missing relationships to the scaffolding.xml file. This will allow the generator to understand that when you are updating any of the primary key fields it should create a validation routine that checks that the value is valid in the other table. The alpha 1 version of the Scaffolder doesn't do this but a later version will. The current version will use that information to create drop down boxes on the generated forms so that you can simply select values rather than have to type them in. To support this you should define those fields in the scaffolding.xml and say what should be displayed in the drop down.

Another thing that may be important to you is the type of control that will be used in the generated forms for each table. If you don't like the scaffolder's default choice you can change it in the xml and make it a different type of control or just change its width.

Once you have done all that, you can delete anything that was generated earlier (except the scaffolding.xml file) and run the scaffolder again. This time missing out the database introspection phase. The scaffolder will regenerate the code based entirely on the contents of the scaffolder.xml file.

Now your code is probably as good as the scaffolder can make it. Its up to you now. In the alpha you should remove the lines of code that trigger the scaffolder and begin to make the code do exactly what you want it to do. There are a couple of useful features in the standard templates that can help here. The fields are created in the same order they are listed in the database tables but it is unlikely that you will want to show them all or in exactly that order.

Each of the display fuses takes a list of fields and when provided it displays the fields on the page in that order. There is no need to change the program extensively at this point just omit any fields you don't want and reorder those you do for each of the page types. I can't remember the number of times I have deleted a field only to find out later that it was really needed after all.

You can also use each display fuse more than once. In each case you can give it a different list of fields so making it very flexible, you can completely change the page by changing the field list. Thanks to Peter Bell for this idea, its a real time saver.

One last thing you might like to do is search out the generated layout.dsp file and modify or replace it to implement the look and feel of your planned site.

At this point you should have a fairly passable prototype to show to your client. More to follow in part 3.

"Oh no my user wants a change!"

Now your code has been generated by the scaffolder you have a difficult choice to make. One possibility is that you could manually change the generated code and so make it do what the client needs that way. The other alternative is to modify the scaffolding.xml file and regenerate. I honestly don't know what the answer is here all I can say is that it depends.

Part 3 will follow soon.