Posted by Steve on 04/23/07 22:01

| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
| ABOUT THE USER LOGGING IN!

imagine if you will/can, that the form carries a tag perhaps identifying
say, an ip address - i know it's a stretch for you. that would certainly be
ONE way to marry an instance of data with a browser. input is stored in a db
with each post/get. when that ip (in this instance) and its data was
analized, we could then still tell where the user left off - or what the
next step would be.

i can come up with several other matching methods. care for more
embarrassment?

| > | > note that as i've said. the chances of losing data due to deletion
is
| > nil.
| > | > what you've described is what i also noted. that an update can cause
a
| > | > partial loss of data but this only involves the data related to the
| > current
| > | > step, and is therefore negliable (with a few caveats).
| > | >
| > |
| > | No one ever said anything about deletion or update. I was
specifically
| > | talking about losing the id to the row which is stored in the
session -
| > | and the session is lost. Nothing more, nothing less.
| >
| > data is in the db. a query will return the correct step that is next in
the
| > ladder of steps to get to the top. user logs back in, that step is
| > displayed. now, pray-tell, HOW IS THE DATA LOST?
| >
|
| ONLY IF YOU HAVE THE PRIMARY KEY TO THE COLUMN!!! IF THERE IS NO LOGIN,
| HOW DO YOU DETERMINE WHICH ROW IT IS?

yelling is not compensating for your lack of imagination. you keep talking
about rows. you realize that in a stepped operation, you are not talking
about just one row of data. each step is probably its own row. i've pointed
out one way to link a browser instance with data...no reason why it can't be
tied to all the related rows. as each row is validated as 'complete', we
simply provide the next set of prompts for input...ad nausium until the
ladder has been summited.

| > | > | > | If you force them to sign in, you could key the data to their
user
| > id;
| > | > | > | then at least it would be saved when the session fails. But
then
| > | > | > | they'll have to log in.
| > | > | >
| > | > | > and when the user logged in again, since the data is in a db
rather
| > than
| > | > a
| > | > | > session, you could bring them to the last step they completed
| > (whether
| > | > there
| > | > | > is already some populated data they hadn't completed or if
they're
| > at
| > | > the
| > | > | > beggining of that step).
| > | > | >
| > | > |
| > | > | And you'll have another session id and another key, unless it is
keyed
| > | > | to the userid, as I mentioned above. But he still has to login
| > because
| > | > | the session disappeared.
| > | >
| > | > yes, the re-log in is a bitch. however i don't recall either you or
i
| > | > addressing this problem. let's stick to the architecture for a
moment
| > then.
| > | >
| > |
| > | It's part of the architecture - and something the op wants to avoid.
| >
| > then wtf don't you just address how he can solve the session problem
instead
| > of giving BAD architectual advice...like, 'a db won't get you any closer
to
| > solving the problem'. as i've pointed out, it DOES allow for a way to
| > recover. you just have no idea how to implement a fail-safe.
| >
| > get over it.
| >
|
| THEN GET OVER IT! THE ARCHITECTURAL ADVICE IS SOLID! AND YOU HAVEN'T
| POINTED OUT ANYTHING EXCEPT "IF THE USER LOGS IN...".

yes, MY design is solid. saying db storage leaves you no better off than
just sessioning the user input is LUDICROUS. btw, that was YOUR advice.

and, i've pointed out MANY ways to do all of this. i can pseudo code a whole
example WITHOUT using logins if that's the only way your pea sized brain can
conceptualize...solidified as concrete!

| And that does solve the problem of the user having to log in.

hmmm...'that' would be what? sessioning data from a browser where the op is
KNOWN to have sessions dropped? i don't see how that does anything BUT drop
the data collected for that user. if you validate and save collected
information with each steps posted info, you won't even lose a NEW
record...nor a modified on.

| > | > don't couple specific data to a user. we don't have to here. if you
want
| > to
| > | > detect the last thing a user was working on, so be it. however
nothing
| > says
| > | > that has to be that way. you may not even see that as desireable
though.
| > | >
| > | > let's say i work at station 4, take lunch but have left a component
to
| > be
| > | > finish by someone else at station 4. after my lunches i begin
working at
| > | > station 5. station 5 is where the build up of astronautic rocketry
is
| > | > performed, while station 4 is where legos are put together to keep
all
| > the
| > | > workers humorous and sane.
| > | >
| > | > you don't want to tie the user data to a step here. what could be
done
| > is
| > | > allow a login with a selection of stations from which he can chose
to
| > work.
| > | > it would then be appropriate to begin the completion of the most
current
| > | > work. that could be automatic, or if multiple components are built
up
| > there,
| > | > they could put in a job id, part id, or any other identifier. having
| > THAT
| > | > identifier pull from already SAVED data will solve a bunch of
problems.
| > | >
| > |
| > | Let's stick to the architecture for a moment then. No one ever said
| > | anything about changing stations, for instance.
| > |
| > | > and btw, NONE of these altertatives i just described are available
| > WITHOUT A
| > | > DB. the ONLY thing one should ever need to session is the logon
| > information
| > | > of the user. anything else is bad architecture.
| > | >
| > |
| > | If there even is a session login. That part is not clear.
| >
| > in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i
said,
| > if you simply select what work you'd like to begin, having a DB will
allow
| > you to query DATA for what is left to do for the task. even without a
login,
| > identifying WHERE the user is performing his job (answering
questions/giving
| > input), you'd be able to give them a LIST of incomplete tasks from which
| > they could pick.
| >
|
| THEN HOW DO YOU DETERMINE WHICH ROW IS ASSOCIATED WITH THAT USER? HOW
| DO YOU KNOW WHICH TASKS ARE COMPLETE AND WHICH ARE INCOMPLETE?

ROWS!!! i've made one suggestion already. i'm sure you've built logical code
before that validates data, right? nothing changes in answering your second
question.

| > sessions WON'T allow you to do that. a DB will...with great flexibility
in
| > ANY context however you implement your access to a process per user. if
you
| > remember, you said a db essentially does shit for the op's problem. you
| > clearly see i beg to differ.
| >
|
| SESSIONS KEEP TRACK OF WHICH ROW IN THE DATABASE IS BEING REFERENCED.

you're not solving anything by using sessions. only complicating minor
problems like dropped sessions.

| > | > | And if the op isn't forcing the user to login, there is no way to
sure
| > | > | way to identify the data.
| > | >
| > | > i think i just described a litany of ways in which your assertion
here
| > is
| > | > utterly foundless.
| > | >
| > | >
| > |
| > | You have? I don't see it. All I see is a bunch of rambling about
| > | completely unrelated possibilities.
| >
| > then you're mind is wholly inable to imagine the TYPE of general
| > functionality the op wants AND can't draw from you previous EXPERIENCE
to
| > correlate different solutions that are applicable to the TYPE.
| >
| > intellect is measure by inference and association. are you saying you
truly
| > see NO similarities between my 'ramblings' and what the op is doing? if
not,
| > i feel for you, bro.
| >
| > | The fact is, if you lose the key to your row, you can't access that
row.
| >
| > data is in the db. a query will return the correct step that is next in
the
| > ladder of steps to get to the top. user logs back in, that step is
| > displayed. now, pray-tell, HOW IS THE DATA LOST?
| >
| >
|
| And your mind is completely unable to grasp a simple concept. If the
| session is lost and there is no user login, there is no way to reference
| the row in the table related to this user.

sure there is...use your imagination.

| You have 500 users currently active. Suddenly one of them loses a
| session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| USER? THERE IS NOT LOGIN!

not a problem.

| And YES I'M YELLING. You don't seem to grasp even a simple concept.

sure i do. in fact, i've got 6 manufacturing plants with over 400
workstations total that all have multi-stepped, conditional routing. in 3
years of it being in service, i've only ever had to go back to add new
reports. everything else, as i high-leveled here, is sound. AND, the only
thing i ever session is the user name and password and a security key.

if you can't grasp that this is NOT dependant on logins, you are only fit to
program in a paper bag from which you cannot break out of.

[Back to original message]