Why Scaffolding Sucks!!!
There is nothing wrong with generating (or using dynamic programming to provide) default controllers, views and model functions. But why bother to write a scaffolding system that you know is going to be thrown away 60-80% of the time?
The problem isn't with scaffolding - it's a good kid with great potential. The problem is the evils of database introspection - a single technique that has put application generation back at least 5 years . . .
I mean, really, whoever came up with the idea that introspecting the database was the right way to get metadata about an application? Database schemas aren't semantically rich enough to provide the metadata required, so we end up with scaffolding that we usually have to throw away because it is way too naive for production.
But there is another way.
Use a richer metadata store (we keep a metabase in SQL server for easy reuse across thousands of projects, but XML or even hand coding a few properties into the init() methods of your custom classes will do fine for starters). Start by giving every attribute a title. (Who wants to see "LastName is a required field" in a professional production application?) Then describe its intent using a set of abstract data types so your application can automatically apply calculations, validations and transformations, so that it can nicely format date or currency displays in your lists and views and so that it can create more intelligent forms with date pickers and wysiwyg editors and drop downs with value lists rather than just text boxes and text areas for editing everything.
Of course, there will still be some work to be done. Some calculations are pretty unique, and front end layout will usually need to be tweaked by a designer, but really, lets use richer metadata so the system can generate at least 80-90% of our application code and we can put it into production rather than generating dumb scaffolding that's going to have to be done over by hand. Who's got time for that?!
Most of my next few posts will be covering the concepts and codes required to implement this utopia. Starting with self describing beans, then going on to describe my implementation of abstract data types in CF and finally looking at the practicalities of dynamic list views, item views, forms and save methods.
Thanks for the comment! I happen to generate the db schema based on the presentationmetadata, but you're right. DB introspection is also required if you don't generate the db schema so you can compare with your application metadata and make sure yu're not allowing people to try to save 500 character text strings in datetme fields!
Best Wishes,
Peter
I have to say that much of what you talk about goes a bit over my head. But I have to say I am very excited to watch as this all comes together. Ever since I heard you talk at the NY-CFUG meeting, I have been a bit scared for my job (in the good sort of motivating way ;)). So anyway, I just wanted to say that it's all exciting and I can't wait to understand it.
NYCFUG was cool - even if the presentation was a little ropey back then - was still trying to figure out how to "tell the story" and covered way too much info in too little time!
Right now I'm mainly proving concepts in code, so it is probably a little hard to get your head around. Eventually I'll do my best to provide some sample apps so people can see this "in the wild" and play with it for themselves!
In the meantime, if there is any particular concept or step that is confusing or not explained well (I'm sure there are plenty!) feel free to post a comment as it'd probably help anyone else reading the post who had the same questions (when I explain something badly I'm sure there are plenty of people who find the same things obtuse!).
Oh, BTW< this particular post is more of a general rant - I haven't even posted on abstract data types yet. I want to play with my implementation a little more before I post about that . . .
Best Wishes,
Peter
Thanks! I sort of telling it all sink it for now, but I will definately post any questions when I know enough to formulate them.
Thought Sam would be keeping you to busy to type!
OK, here's my opinion. My opinion (worth somewhat less than 2c at the current exchange rate) is that the only compelling use for db introspection is to know what the database looks like - period.
I really don't think it should be used for anything else (in an ideal world).
One of the things I'm toying with is a metabase starter kit which introspects your database and allows you to select the columns you'll be working with, alias them, set titles for them and associate an absract data type to them (US phone number, SSN, birthdate, etc.). That would be a way of jumpstarting the creation of metadata for a system that had a seperate DB schema.
I really don't like db introspection for generating components because of the magic "human intervention required". If you can't generate your schema, I'm open to db introspection for confirming that your object model will map to your schema, but I don't really even like it for generating components because you're back to scaffolding and "creating starting points" whereas I really like to generate almost everything, only hard coding into custom classes stuff that can't be generated (because I'm currently too stupid about it to generate it).
The real killer with "human intervention" is that you're back to passive 1 time generators which would be fine if data models and requirements never changed. I think passive generators are a good learning exercise and if you don't HAVE an active generator they're better than nothing, but in my ideal world they would be sent to the same level of hell as immoral used car sales people and programmers who name all of their variables "a", "b", and "c"!
Best Wishes,
Peter
Some applications are really just written as a front-end for an existing database. In which case, your application should be defined by the structure of your database.
More frequently, however, your database is built to store data for your application. In that case, your application should dictate the structure of the database.
I'm actually going to disagree a little. Even if your application is based on your database, the database doesn't have sufficient information to create useful scaffolding. I don't need to know that Home Phone is a varchar(15) - I need to know that it is a phone number so I can automatically apply the common sense transformations, validations, field display and formatting rules that apply to a phone number rather than just displaying a text box and making sure that the value contains no more than 15 characters.
Sufficientl well designed, scaffolding can BE 95% of the application, but only if you user a richer set of meta data than database reflection is capable of providing. In short, whether your application is based on your database or vica versa, I contend that scaffolding stil sucks!!!
That is a good point.
I think that means that scaffolding based only on database structure will yield an anemic application. I would certainly agree that any scaffolding should ideally be built from a richer set of data.