Re: Can CGI Do this ??? -- WEB400

At 02:09 PM 10/22/02, you wrote:

At 13:44 22.10.2002 -0500, you wrote:

I'd prefer comparing the changed values to the actual values in the file,
not the stored ones in any state holder or hidden fields. That would make
more sense in a generic way.

How do you know that the actual values in the file haven't been changed by
another user?  If you truly do want a read next changed operation, the only
real way to know is to compare to a saved copy of the data.  It could be in
some kind of session object, or you could have the client return the before
and after versions of the data, but I don't think you could compare to the
data file, as in 'Chain to the file to see if the record is different.  If
so, post these differences as changes"

Yes, one needs three sets of data -
the original data sent to the browser,
the possibly altered data from the browser
and the current content of the file.

Yes! Exactly correct!

If the current content isn't equal to the one sent to the browser,
someone/something else has altered the data in the meantime.
This functionality is even provided by UPDDTA. Never seen DFU0865?

Uh, no.  I don't use DFU, generally.  But I know what it is!

And the "read next changed" is just an analogy to READC that just reads
those lines "touched". But that doesn't really fit here. Everything has to
be read from the browser; by means of JavaScript one could know that a
field has been "touched" instead of comparing to somehow saved or database
values. But that isn't really reliable from my point of view.

Hmm.  Read next changed is the correct *concept*.  If I'm using the browser
to simulate an input capable subfile, I do not want to update records in my
database if they have not been changed.  It generates additional traffic to
the database that is unwanted, and unneeded.  Therefore, I must have a
mechanism for determining if the data coming from the user is different
that the original data.  I would never rely on javascript for that, many
browsers do not support it, and many users simply turn it off due to
security concerns.

The stateless way is to give the browser a hidden copy of the original data
along with the input fields.  The stateful way is to generate a session
object and store it on the server, hopefully just in memory, and then have
the client return a session id along with the updated data.  I do it both
ways, depending on the circumstance.

Regards,
Rich