I just want to comment on the table itself and code generation. In the table sense you are examining pieces overall to determine what to do, and how, which relates to how things are coded. But the ability to look at the "big picture" for the person defining the table isn't available to the person writing the code. each item needs to be checked, and as the table becomes more complex the lookups follow suit. The way many algorithms tackle this is by weeding out exceptions early, then based on what is left focus on doing something in particular... I think an example might be in order, so lets take your table and transform it to a "coding paradigm"...
cause Im lazy, nesting in code tags is easier...
## Original table from business flow perspective..
name email add emailexist step:
T T T T warn 1. email exists in database
T T T F action 1: add email in database
T T F T action 2: remove email from database
T T F F warn 2. email doesn't exist in database
T F - - warn 3. email empty
F T - - warn 4. name empty
F F - - warn 5. name and email empt
# New table from code perspective..
name email add emailexist step:
F F - - action 1: fail not enough input
T F - - action 2: fail not enough input(email)
F T - - action 3: fail not enough input(name)
- - - - can we talk to DB? ( what do we do if we can
- - - - do we have read/write access to DB? ( what d
+o we do if we dont? )
- - T/F - what are we doing?
- - T - we are adding
- - T T action 4: error email already exists
- - T F action 5: add email to database
- - F F action 6: fail cant remove what isnt there (
+ or is this ok? based on what? should this be fatal? should it collec
+t more info? from where if so? )
- - F T action 7: remove email from DB
Now you will notice there are far more dashes in the second table.. because by the time we get to those points in the code, the other data points dont matter, because they have been checked and dealt with (sanitize, etc..)
So while I think the idea of creating say a template/table of some sort that will produce code is a noble idea, it's one people have wrestled with for a *long* time. I mean look how simple HTML is, and yet there are relatively few (none in my knowledge, but I'm not that knowledgable so Im acknowledging they may be out there) HTML composers that produce clean sane, trim HTML which doesnt even have a loop structure... what about localization of data? what about configuration changes based on multiple backends or multiple frontends? what about multiple workhorses (i.e distributed computing, or thereabouts) for single/multiple front/backends? what about code speed optimizations? what about creating sub functions to deal with similar occurances of say particular checks used by multiple other pieces of code (i.e input sanitation/validation)?
From the human perspective it is very easy to look at something and say this goes with that, whereas in code it usually takes some expertise somewhere along the way to give the "appearance" that things are actually logically connected. I mean simply examine OOP. This and that are derivitives of this thing. Look at all the semantics involved with it, we can't even decide how to definitivly define what new() should be (tounge in cheekish)...
/* And the Creator, against his better judgement, wrote man.c */