Board index » delphi » TechTips: Using table-driven logic

TechTips: Using table-driven logic

Here's food for thought.

There are two kinds of code in an application:  (1) the code that enables the
application to perform a primitive function, like running a query or producing
a report or popping a certain dialog box; and (2) the sequencing logic that
ties it all together.

Applications usually grow by adding more sequences of possibilities on top of
a much smaller, well-defined set of (application specific, more-or-less)
primitive functions.  "The language itself," of course, is the first and most
base level of primitive functionality, but each app that you develop
necessarily builds a foundation on top of that.  However, each application has
one.

What becomes redundant and time-consuming and costly, really, is the
sequencing logic .. what's just beneath the skin of the GUI and just above the
primitive foundation layer.

For situations like this, think very carefully about using "table driven
logic."  The program works by carrying out sequences of operations and
decisions that it reads from a (read-only) table.  The program can be
customized, or even repaired and enhanced, without writing a single line of
new code.

It's a phenomenal technique and not used nearly often enough.

/mr/
http://www.sundialservices.com/

 

Re:TechTips: Using table-driven logic


Quote
bill collins wrote:

> > What becomes redundant and time-consuming and costly, really, is the
> > sequencing logic .. what's just beneath the skin of the GUI and just
> above the
> > primitive foundation layer.

> > For situations like this, think very carefully about using "table driven
> > logic."  The program works by carrying out sequences of operations and
> > decisions that it reads from a (read-only) table.  The program can be
> > customized, or even repaired and enhanced, without writing a single line
> of
> > new code.

> > It's a phenomenal technique and not used nearly often enough.

> > /mr/
> > http://www.sundialservices.com/

I agree-we use "control" tables a lot that is the brains driving the code-many of the changes you have to make
is not in your code but rather just changing a field in your "control" table or by inserting or deleting
records-it's a little more time consuming to develop up front but a great time saver in terms of maintenance.

Dale

Re:TechTips: Using table-driven logic


I couldn't agree more...I have used this type of sequencing in a couple of
DOS based Pdox applications and found that it offers great flexibility and
makes one think in modular terms...As a side benefit, but not unimportant,
your application becomes self documenting.
--

Sundial Services <news-re...@sundialservices.com> wrote in article
<news-reply.5945.02688...@sundialservices.com>...

Quote

> Here's food for thought.

> There are two kinds of code in an application:  (1) the code that enables
the
> application to perform a primitive function, like running a query or
producing
> a report or popping a certain dialog box; and (2) the sequencing logic
that
> ties it all together.

> Applications usually grow by adding more sequences of possibilities on
top of
> a much smaller, well-defined set of (application specific, more-or-less)
> primitive functions.  "The language itself," of course, is the first and
most
> base level of primitive functionality, but each app that you develop
> necessarily builds a foundation on top of that.  However, each
application has
> one.

> What becomes redundant and time-consuming and costly, really, is the
> sequencing logic .. what's just beneath the skin of the GUI and just
above the
> primitive foundation layer.

> For situations like this, think very carefully about using "table driven
> logic."  The program works by carrying out sequences of operations and
> decisions that it reads from a (read-only) table.  The program can be
> customized, or even repaired and enhanced, without writing a single line
of
> new code.

> It's a phenomenal technique and not used nearly often enough.

> /mr/
> http://www.sundialservices.com/

Re:TechTips: Using table-driven logic


Can you give an example of how table logic works?

Mark Shapiro
info...@swbell.net

Re:TechTips: Using table-driven logic


Quote
Sundial Services wrote:

> Here's food for thought.

> There are two kinds of code in an application:  (1) the code that enables the
> application to perform a primitive function, like running a query or producing
> a report or popping a certain dialog box; and (2) the sequencing logic that
> ties it all together.

I agree!  I started building an app last year and just last week
discovered table base logic.  I only wish I had thought of it a year
ago.

Mark

Re:TechTips: Using table-driven logic


I read everything I can get my hands related to Delphi and I've never
come across "table-driven logic."  Can you provide a specific example of
what it is?  Is it storing code fragments or units in tables?

Re:TechTips: Using table-driven logic


Quote
Sundial Services wrote:

> In article <33F3D8C8....@worldnet.att.net> Al Solter <asol...@worldnet.att.net> writes:

> >Perhaps I'm reading something into this but...

> >I use tables, or .ini files to support parameter driven systems, so if
> >you are referring to using table parameters to manipulate your in-line
> >code, I agree with you, but, in my opinion, if you are actually running
> >code modules which are stored in a table, this has as many drawbacks at
> >it does advantages.  I've tried it and I didn't like it.  It is messier
> >to implement, it cannot be syntax checked in the table, and (pardon me
> >for running it on 486/33 PCs), it is slower than in-line or library
> >code, which can sometimes make a big difference.

> No, Al, I'm not recommending grabbing code-modules from the table.

> What I am recommending is that a table can be used to, for example, create a
> report-menu and stipulate the steps required to run the report.  (In fact, we
> sell our version of that as a product.)  It can also be used to implement
> internal processing procedures of all kinds -- I recently saw an interesting
> time-clock program (VisiBar) that essentially used this technique to do
> *everything.*

> The design technique is basically that, many repetitive operations consist of
> a smaller sequence of actions -- like running a query, opening a dialog box,
> and so on -- but there is relatively little decision-making in how you
> describe the process.  You could "write a list of instructions and give it to
> a person."  You can do the same thing with a computer.

> The main line of such a program is basically a big CASE statement, with an
> operative routine for each type of sequence-step you have defined.  Once you
> have defined all of the steps you need, your "traditional programming" task
> ends.  Now you are simply assembling the pieces in different ways.  This
> approach allows you to respond to user changes very quickly.

> In one application we have had for about four years now, there is probably
> half a megabyte of total code, forms and etc.  But there are, or have been
> over time, nearly 100 different reports and 80-odd transaction sequences or
> variations thereof -- all of them entirely table-driven.  The complexity of
> maintaining this application is many times less than it otherwise would be,
> simply because of the sequencing.

> Part of what I'm trying to do is simply to put out "food for thought for
> programmers."  This is an idea that has worked out tremendously well for us.

I see said the blind man...

I actually did do something like this about two years ago.  I've had a
lot of ideas on ways to make it better since then but have never had the
opportunity to go back and improve upon it.

Basically, the code would be in a library, the name of the report, the
method name and the uses statement would be in the table.  When the user
double clicks the name of the report in the table frame, it would update
the application uses statement and run the method.  I never got around
to trying the part about the uses statement so I don't know if it will
work, but I have done similar things in other applications since then,
so it feels right.

Best tool I ever saw was one where standardized pieces of debugged code
were stored in a table, and could be selected with checkboxes and run
against a new form to place the standard code into the built-in methods
on a new form.  Saved a ton of cut and paste.

Al

Re:TechTips: Using table-driven logic


Quote
Sundial Services wrote:

> Here's food for thought.

> There are two kinds of code in an application:  (1) the code that enables the
> application to perform a primitive function, like running a query or producing
> a report or popping a certain dialog box; and (2) the sequencing logic that
> ties it all together.

> Applications usually grow by adding more sequences of possibilities on top of
> a much smaller, well-defined set of (application specific, more-or-less)
> primitive functions.  "The language itself," of course, is the first and most
> base level of primitive functionality, but each app that you develop
> necessarily builds a foundation on top of that.  However, each application has
> one.

> What becomes redundant and time-consuming and costly, really, is the
> sequencing logic .. what's just beneath the skin of the GUI and just above the
> primitive foundation layer.

> For situations like this, think very carefully about using "table driven
> logic."  The program works by carrying out sequences of operations and
> decisions that it reads from a (read-only) table.  The program can be
> customized, or even repaired and enhanced, without writing a single line of
> new code.

> It's a phenomenal technique and not used nearly often enough.

> /mr/
> http://www.sundialservices.com/

Perhaps I'm reading something into this but...  

I use tables, or .ini files to support parameter driven systems, so if
you are referring to using table parameters to manipulate your in-line
code, I agree with you, but, in my opinion, if you are actually running
code modules which are stored in a table, this has as many drawbacks at
it does advantages.  I've tried it and I didn't like it.  It is messier
to implement, it cannot be syntax checked in the table, and (pardon me
for running it on 486/33 PCs), it is slower than in-line or library
code, which can sometimes make a big difference.

Re:TechTips: Using table-driven logic


Quote
In article <33F3D8C8....@worldnet.att.net> Al Solter <asol...@worldnet.att.net> writes:
>Perhaps I'm reading something into this but...  
>I use tables, or .ini files to support parameter driven systems, so if
>you are referring to using table parameters to manipulate your in-line
>code, I agree with you, but, in my opinion, if you are actually running
>code modules which are stored in a table, this has as many drawbacks at
>it does advantages.  I've tried it and I didn't like it.  It is messier
>to implement, it cannot be syntax checked in the table, and (pardon me
>for running it on 486/33 PCs), it is slower than in-line or library
>code, which can sometimes make a big difference.

No, Al, I'm not recommending grabbing code-modules from the table.  

What I am recommending is that a table can be used to, for example, create a
report-menu and stipulate the steps required to run the report.  (In fact, we
sell our version of that as a product.)  It can also be used to implement
internal processing procedures of all kinds -- I recently saw an interesting
time-clock program (VisiBar) that essentially used this technique to do
*everything.*

The design technique is basically that, many repetitive operations consist of
a smaller sequence of actions -- like running a query, opening a dialog box,
and so on -- but there is relatively little decision-making in how you
describe the process.  You could "write a list of instructions and give it to
a person."  You can do the same thing with a computer.

The main line of such a program is basically a big CASE statement, with an
operative routine for each type of sequence-step you have defined.  Once you
have defined all of the steps you need, your "traditional programming" task
ends.  Now you are simply assembling the pieces in different ways.  This
approach allows you to respond to user changes very quickly.

In one application we have had for about four years now, there is probably
half a megabyte of total code, forms and etc.  But there are, or have been
over time, nearly 100 different reports and 80-odd transaction sequences or
variations thereof -- all of them entirely table-driven.  The complexity of
maintaining this application is many times less than it otherwise would be,
simply because of the sequencing.

Part of what I'm trying to do is simply to put out "food for thought for
programmers."  This is an idea that has worked out tremendously well for us.

Re:TechTips: Using table-driven logic


This sounds like merely deriving a finite state machine for
whatever operation need to be performed and then activating
the automaton to carry out the actions.

This isn't a new technique in programming by any means,
in fact, has been around since essentially the beginning
of programming.

Any communications program, for example, really has to
be implemeneted in this way because it is typically juggling
multiple activities (reading from a connection, writing to a
connection, queuing/dequeing, yada, yada, yada) which
might be in multiple threads of execution.

John

Quote
news-re...@sundialservices.com (Sundial Services) wrote:
>In article <33F3D8C8....@worldnet.att.net> Al Solter <asol...@worldnet.att.net> writes:
>>Perhaps I'm reading something into this but...  
>>I use tables, or .ini files to support parameter driven systems, so if
>>you are referring to using table parameters to manipulate your in-line
>>code, I agree with you, but, in my opinion, if you are actually running
>>code modules which are stored in a table, this has as many drawbacks at
>>it does advantages.  I've tried it and I didn't like it.  It is messier
>>to implement, it cannot be syntax checked in the table, and (pardon me
>>for running it on 486/33 PCs), it is slower than in-line or library
>>code, which can sometimes make a big difference.
>No, Al, I'm not recommending grabbing code-modules from the table.  
>What I am recommending is that a table can be used to, for example, create a
>report-menu and stipulate the steps required to run the report.  (In fact, we
>sell our version of that as a product.)  It can also be used to implement
>internal processing procedures of all kinds -- I recently saw an interesting
>time-clock program (VisiBar) that essentially used this technique to do
>*everything.*
>The design technique is basically that, many repetitive operations consist of
>a smaller sequence of actions -- like running a query, opening a dialog box,
>and so on -- but there is relatively little decision-making in how you
>describe the process.  You could "write a list of instructions and give it to
>a person."  You can do the same thing with a computer.
>The main line of such a program is basically a big CASE statement, with an
>operative routine for each type of sequence-step you have defined.  Once you
>have defined all of the steps you need, your "traditional programming" task
>ends.  Now you are simply assembling the pieces in different ways.  This
>approach allows you to respond to user changes very quickly.
>In one application we have had for about four years now, there is probably
>half a megabyte of total code, forms and etc.  But there are, or have been
>over time, nearly 100 different reports and 80-odd transaction sequences or
>variations thereof -- all of them entirely table-driven.  The complexity of
>maintaining this application is many times less than it otherwise would be,
>simply because of the sequencing.
>Part of what I'm trying to do is simply to put out "food for thought for
>programmers."  This is an idea that has worked out tremendously well for us.

Re:TechTips: Using table-driven logic


In article <5t2tdu$an...@s3000-01.magna.com.au> josbo...@magna.com.au (josbo...@magna.com.au) writes:

Quote
>This sounds like merely deriving a finite state machine for
>whatever operation need to be performed and then activating
>the automaton to carry out the actions.
>This isn't a new technique in programming by any means,
>in fact, has been around since essentially the beginning
>of programming.
>Any communications program, for example, really has to
>be implemeneted in this way because it is typically juggling
>multiple activities (reading from a connection, writing to a
>connection, queuing/dequeing, yada, yada, yada) which
>might be in multiple threads of execution.
>John

Yes, this logic basically is an example of an FSM, except that it's simpler
than that.

A Finite State Machine (FSM), gentle reader, is logic that is table-driven
based on a two dimensional table.  The row number is the "state," and this is
initialized at some known value such as 1.  The column number is the stimulus
-- the things that can come in to affect what the system should do next.  Each
cell in the table contains:  (1) an action code, or zero; and (2) the "new
state."  The FSM looks up the action code, carries out the action, then sets
"state" to its new value.

An FSM's state-table can therefore encapsulate a very complicated decision
tree within the table itself.  The programming needed to implement the FSM is
rock-dead-simple and very fast.

But what we are talking about is (or can be) simpler yet.  In the table driven
logic that I use throughout applications, there's basically only one
sequential series of steps being carried out -- very little decision making,
basically a one-dimensional table.  But, as with an FSM, voluminous logic that
would otherwise have to be coded as repetitive subroutines or scripts is now
embedded in an easily modifiable table.

The much-maligned "Macro" feature in Microsoft Access is, of course, an
example of this kind of logic.  Unfortunately, the concept became politically
incorrect within Microsoft before it could be fully developed.

Re:TechTips: Using table-driven logic


Quote
In article <33F50671.5...@worldnet.att.net> Al Solter <asol...@worldnet.att.net> writes:
>Best tool I ever saw was one where standardized pieces of debugged code
>were stored in a table, and could be selected with checkboxes and run
>against a new form to place the standard code into the built-in methods
>on a new form.  Saved a ton of cut and paste.
>Al

Hmm... wanna write a TechTip on that?  :-)  That sounds like a really clever
idea.

Best use of boilerplating since they invented lawyers.

Re:TechTips: Using table-driven logic


On 15 Aug 1997 09:51:01 -0700, in comp.lang.pascal.delphi.databases

Quote
you wrote:

[deletia]

Quote
>What I am recommending is that a table can be used to, for example, create a
>report-menu and stipulate the steps required to run the report.  (In fact, we
>sell our version of that as a product.)  It can also be used to implement
>internal processing procedures of all kinds -- I recently saw an interesting
>time-clock program (VisiBar) that essentially used this technique to do
>*everything.*

>The design technique is basically that, many repetitive operations consist of
>a smaller sequence of actions -- like running a query, opening a dialog box,
>and so on -- but there is relatively little decision-making in how you
>describe the process.  You could "write a list of instructions and give it to
>a person."  You can do the same thing with a computer.

>The main line of such a program is basically a big CASE statement, with an
>operative routine for each type of sequence-step you have defined.  Once you
>have defined all of the steps you need, your "traditional programming" task
>ends.  Now you are simply assembling the pieces in different ways.  This
>approach allows you to respond to user changes very quickly.

>In one application we have had for about four years now, there is probably
>half a megabyte of total code, forms and etc.  But there are, or have been
>over time, nearly 100 different reports and 80-odd transaction sequences or
>variations thereof -- all of them entirely table-driven.  The complexity of
>maintaining this application is many times less than it otherwise would be,
>simply because of the sequencing.

>Part of what I'm trying to do is simply to put out "food for thought for
>programmers."  This is an idea that has worked out tremendously well for us.

All this sounds great, but it's still rather hazy to me how such a
sysetm is actually implemented.  Do you have a small example you could
pass on, or a book or article reference, or perhaps you could prepare
one yourself?

Regards,

Stephen Posey
slpo...@concentric.net

Re:TechTips: Using table-driven logic


Quote
Sundial Services wrote:

> In article <33F50671.5...@worldnet.att.net> Al Solter <asol...@worldnet.att.net> writes:

> >Best tool I ever saw was one where standardized pieces of debugged code
> >were stored in a table, and could be selected with checkboxes and run
> >against a new form to place the standard code into the built-in methods
> >on a new form.  Saved a ton of cut and paste.

> >Al

> Hmm... wanna write a TechTip on that?  :-)  That sounds like a really clever
> idea.

> Best use of boilerplating since they invented lawyers.

I'd like to help out, but I only saw this once.  It was demoed for me at
a job interview at a small software company in Boulder,Colorado.  They
were bought out by Interlink, in Denver, about a year ago.  It was a
tool they had developed for internal use only, but if there was a
demand...  

The alternative of course is to write it yourself, and from what I saw
and from the similar things I have already done, it was no quick and
dirty job.  The specifications alone would be enough to make it into a
full-fledged project.  I admit, it would be fun to do.

Al Solter

Re:TechTips: Using table-driven logic


Yes, and creating a state machine system like this can be a real
life saver.

An app I worked on some time ago consisted of an auditing system
for standardized review surveys. At any given point, a question
could be worth a variable number of points, and would cause
later questions to be required, ignored, etc. depending on the
answer. (In fact some questions were typically worded differently
depending on the situation)

Now, this could have been done straight-forward, by hard-coding this
information about the surveys flow of information, but it would have
been much too inflexible. And since this survey would be changed about
every 3 months, it would be too much work for me to keep up with.
( I had a real job on the side at the time :)

The answer of course was a state machine type of setup.

The end result consisted of a table filled with indexed entries,
and primitives for acting on objects, testing values, saving,
and referencing data in other tables, and branching to other
questions.

This was all read, parsed, and interpreted at runtime to
facilitate the actual data entry.

Thus, the survey became an interactive program that was stored as
text data in several tables in the database. It was completely
re-programmable and adjustable without re-working *any* of the
Access Basic parts, so once they were de-bugged and verified,
they could safely be ignored when makeing conversions.

So I don't know precisely where this conversation started, but using
a sort of interpreted pseudo-code can be a powerful tool sometimes.

I always store configuration info in the database itself. This way I
don't need to care if Access gets updated to a variation of windows
that may or may not support whatever API driven method I pick.
(Like Registry entries and INI files)

At any rate, that's some of my experience in the matter, thought some
of you might be interested.

(And I bet you can't tell that I actually impressed myself on that
 project. :)

------------------------------------------------------------------
George Kinney
The Unknown Programmers
gkin...@usa.net

josbo...@magna.com.au wrote in article
<5t2tdu$an...@s3000-01.magna.com.au>...

Quote
> This sounds like merely deriving a finite state machine for
> whatever operation need to be performed and then activating
> the automaton to carry out the actions.

> This isn't a new technique in programming by any means,
> in fact, has been around since essentially the beginning
> of programming.

> Any communications program, for example, really has to
> be implemeneted in this way because it is typically juggling
> multiple activities (reading from a connection, writing to a
> connection, queuing/dequeing, yada, yada, yada) which
> might be in multiple threads of execution.

> John

> news-re...@sundialservices.com (Sundial Services) wrote:

> >In article <33F3D8C8....@worldnet.att.net> Al Solter
<asol...@worldnet.att.net> writes:

> >>Perhaps I'm reading something into this but...  

> >>I use tables, or .ini files to support parameter driven systems, so if
> >>you are referring to using table parameters to manipulate your in-line
> >>code, I agree with you, but, in my opinion, if you are actually running
> >>code modules which are stored in a table, this has as many drawbacks at
> >>it does advantages.  I've tried it and I didn't like it.  It is messier
> >>to implement, it cannot be syntax checked in the table, and (pardon me
> >>for running it on 486/33 PCs), it is slower than in-line or library
> >>code, which can sometimes make a big difference.

> >No, Al, I'm not recommending grabbing code-modules from the table.  

> >What I am recommending is that a table can be used to, for example,
create a
> >report-menu and stipulate the steps required to run the report.  (In
fact, we
> >sell our version of that as a product.)  It can also be used to
implement
> >internal processing procedures of all kinds -- I recently saw an
interesting
> >time-clock program (VisiBar) that essentially used this technique to do
> >*everything.*

Go to page: [1] [2]

Other Threads