Mike Tuller wrote:
> So I would have the progressive key inside the addvolume window? Can you
> explain how to go about doing this?

How you organize your HTML output should *never* interfere with the way 
you organize your data, they are two different things and must be kept 
well separated. In a perfect world design, process flow and datamodeling 
should be free to evolve without stepping into each other's way. It's 
obviously impossible to fully meet this condition in the real world, but 
one should always try and get as close to it as he can.

Just do this:

Think of your data as a temporary table, in which you have two keys:
1) the real key, whenever available (will be blank on the stuff you 
haven't written in the database yet)
2) a progressive key, assigned by your php scripts by some means

You just have the two keys constantly in your forms as hidden fields, so 
that at process time you can still tell which is which when it comes to 
relations, even if you do not have an already established relation 
system (which is the case on new data).

you load your hdw components, they all have a db id already, so your 
dataset will look like this:

1) hdw 1, its real id, your own internal key (say 1), rest of the data
2) hdw 2, its real id, your own internal key (say 2), rest of the data

you add a new component and save the result on a temporary table, now 
your temporary dataset is:

1) hdw 1, its real id, your own internal key (say 1), rest of the data
2) hdw 2, its real id, your own internal key (say 2), rest of the data
3) hdw new, no real id, your own internal key (say 3), rest of the data

You add a new volume and stock the data on a second temporary table, 
which contains:

1) vol 1, no real id, your own hdw internal key (should be 3 since you 
are adding to the last new hdw), your own internal volume id (say 1), 
rest of the data

You can repeat this step all over as much as you want (like fully 
building up a number of new disks, volumes or whatever), and have it as 
multilayered as you want (it will just take as many temporary tables as 
are the real tables involved).

Once your user finally reviews his/her data (say you entered a totally 
new system, reviewed it and felt satisfied with it) he will have a 
"fire" button somewhere.

At this point your final script just takes the data off the temporary 
tables and uses them to build the real thing.

Notice that this way you also sort of implemented a transaction. Not a 
real one, since it will not protect you if your final script fails at 
runtime. Yet you can be sure no unconsistent data from unterminated 
sessions will ever enter your stable datamodel, and that's were 99.99% 
of the risk would come from.



LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is.......

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to