Привет!
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).
So:
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
