|
|
Posted by Steve on 04/24/07 03:59
| Sure, fire away. You've already made an ass of yourself several times.
| Keep it up!
and when was this exactly?
| > 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.
| >
|
| No, but it seems to be the only way you can understand what anyone else
| is saying.
you still have yet to make a point. whether you yell or not doesn't get you
there.
| I'm still waiting for you to come up with a way to indicate how to
| recognize the appropriate row(s). So far you haven't.
i'm still waiting for you to unveil AN example of where sessioning data is >
db data. i suspect you haven't because it is not and you cannot because of
that.
| > 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.
| >
|
| As solid as swiss cheese. Glad you aren't working for me.
i'm suprised you are working at all. now, show sessioning data is better
than storing it in a db. the best you can do is say they are equal when
there is no unique identifier.
| > 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!
|
| You've pointed out NO WAY to do this - other than to require a logon, an
| ip address or similar.
there are several...the best would be a login. even without all that, if a
session is lost then so is the data - in THAT case if there is not unique
identifier, then all that is shown is that in that aspect, the two
approaches are equal. yet, i've given several options available that apply
to data sharing, recovery, etc. where db storage is the only way to acheive
those basic tasks. you cannot provide even one that shows how sessioning
data would scale...even in different circumstances.
| >
| > | And that does solve the problem of the user having to log in.
| >
|
| No, you haven't shown any way to do it.
|
| > 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.
| >
|
| And how do you point to the appropriate record?
via a login in the most common of situations. but, since that's the only
requirement, you go ahead and pick at it..failing to realize that not
utilizing a unique identifier AT BEST only makes sessioning data == db
storage...you still have yet to show it being BETTER than db storage. give
it a try. oh yeah, you can't because it is not. try anyway. a real-world
example. i'll wait.
| > 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.
| >
|
| You mean one asinine suggestion which works only if you can guarantee
| there is concurrent access - or you require a user to login.
clearly you don't get it. worst case scenario is i have no login and am
sessioning a unique id among the collected ROWS, the session is dropped.
that leaves both db and sessioning data in the crapper. the two methods are
equal in that light. however, there are a bunch of ways to grow/scale what
you can do if the data is not restricted just to sessioned data (which
cannot be stored indefinitely or shared simultaneously among other clients).
your claim was that db storage was no better than sessioning data. the OP
never mentioned whether there was/not a login involved. i made several cases
of the benefits of db storage...proving you wrong. and at best, you are only
right in one limited context. however, in that context, even when equal
effects ripple, the db storage architecture can be scaled. sessioning data
is very limited in functionality.
but you just keep plugg'n away. you're not making any heads turn.
| Steve,
|
| It's pretty obvious you're a "wanna-be" with no real understanding of
| how the internet works, nor do you have any idea how to develop a secure
| application.
funny how this is your standard retort when i call you on the carpet when
your advice is bad. you offer no valid support to your original claims nor
counters that make mine seem less than valid. and, when all else fails, you
make even more broad claims of what you 'feel' my experience level is.
i'd say either a valid point that you can maintain or some debate classes
would serve you well.
| As I said before - I'm glad you aren't working for me. If you were, you
| wouldn't be for long.
again, you're employed?
| But you're a typical troll - all the answers and refuse to see the
| weakness of any of them.
at least i state my case, give examples of them, and logically defend them.
you just babble bullshit and hope it sticks.
whatever
| What do you have - three months of experience in programming? Maybe less?
more like 20+ ... but that's ok. console yourself to whatever helps you
sleep better at night.
| As for the "clients" you mentioned in previous posts. Now you've also
| proven you're a liar. I HAVE worked for some of these clients. And
| none of them would hire anyone with your "credentials".
really? and what 'credentials' would those be? have i stated them? no, just
for whom i've worked. and, which clients would those be? i'll be happy to
throw some names of those with whom you would have had to work with. you
tell me their titles and i'll believe you. btw, they won't be easy to
google.
and, as out-of-touch as you are with reality, it's not hard for me to
believe that your mistakes would not be limited to programming, but to
personnel as well.
Navigation:
[Reply to this message]
|