I think John makes a valid point in making a distinction between "data driven" at runtime vs. compile time. I agree with him that anything that can be done once at compile time, vs. penalizing the end-user every time at runtime, should be done.

I have some experience with the old VFE5 framework, which by default is very data-driven. Fortunately it offers a mode to write data dictionary values permanently and not reset them at runtime, once you have finished development. I found that form load times dropped to about one-third after doing this (i.e. a complex form would load in 3 seconds instead of 10).

At the moment, hardware is cheap and fast, and has "gotten ahead" of software. We tend to take this for granted. I find it useful once in a while to create a VFP baseclass form, populate it with baseclass controls and manually set the properties, and look at how fast it loads. It's a real eye-opener if you've been buried deep in the world of hierarchical class libraries and data-driven architectures for some time.

Just my CAN$0.02

>Hello John,
>
>Normally I agree with much of what you say, but I find driving apps with data to be very useful, with a big payback. It may not be worth doing for a single isolated app, but I design in a way that things can be reused in other apps.
>
>Data driven objects make for a very object oriented projects. Functionality and flexibility can be built in at very low levels and changes can be accomplished quickly, even by the end user, without recompiling the app.
>
>The overhead for this type of thing is not that great if implemented correctly, for example, VFP classes, forms, and reports are data driven :-). I find these techniques particularly useful when working with grids. I have a base class grid object which I can define the order and width of colums, if the column is editable, automatic calculated sums, etc. By having this data driven, I can drop the grid object on the form and set it up entirely with data, saving tons of time. If I need to change the order of a column or add/remove a column, takes only seconds.
>
>I little extra work up front, gives me a tool with a payback a hundred times over. Just my opinion....
>
>Bob
>
>>First, with respect to data-driven applications. Typically,these beasts are data-driven at runtime. Given the overhead involved, I have to ask what is the real return. Of course, when I say overhead, I am talking in terms of cost and processing time.
>>
>>When I hear about data-driven solutions, invariably, it ends up being a situation where the developer thinks that what he has done is super cool. Look at what I did!!! Typically, it ends up being what is normally a 200 dollar problem being solved with a 2000 solution. I am OK with this sort of thing if the additional $1800 investment is going to have a payback. Me as a developer thinking it is cool is not an economically justifiable argument.
>>
>>Canned soltuions like Steve Black's INTL toolkit, and its use of a data-dictionary make sense since that is central to the problem being solved. Data-
>>Of course, I would still advocate compile time solutions as opposed to run-time solutions. Purely a preference on my part.