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.