× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



At 21:22 21.10.2002 -0600, you wrote:
> From: "Anton Gombkötö" <gombkoetoe@ASSOFT.COM>
> I don't understand the word "state" in this; what has it to do with,
> say, 50 lines with checkboxes, input fields and so on?

Sorry for not being more clear.
I think it's definitely me standing on the line.

  The subfile may be sent to the browser with
one set of values, then returned to the program with a different set of
values.  In a sense, the original set of values would be one "state" for
each subfile record, and the return values would be another.  A "subfile
next change" operation would need to compare and flag the difference for
each record.
Ah, yes. I see.

Rich Duzenbury suggested downloading two sets of field values so that one
set might be compared against the other.  The code for that could become
cumbersome, easily, and is only a partial solution.

A change in a subfile record may trigger an output operation to the browser.
Consider, for example, a subfile option column that triggers a record Copy
or Change operation.  The back-end program needs to activate a dialog in
which the Change or Copy forms are shown to the user and returned to the
program for each subfile record that was "flagged".  The overall process
would span multiple requests from the browser.
Yes, i can imagine that this can get pretty complicated without a "state
holder" in the background.

Consider that during the course of the dialog a single CGI job may handle
requests from multiple concurrent users, and that a single user's requests
may be handled by multiple CGI jobs.  The question is how Net.Data macros or
comparable CGI procedures might handle that?
There is the functionality of persistent macros in Net.Data which could be
used for that. Many people disrecommend the use of them. I tried them, they
work, but it can get users into nirvana when they press the "back" button.
So i also prefer to not use them.

For the above scenario exist a couple of solution "paths"; whether it's
Net.Data or anything else.

First of all, nobody should code a CGI that RETURNs and expect that this
very program is called again by the same user with the next step of a
transaction.

In Net.Data, everything is "clean", except you made it dirty yourself (e.g.
library list).

So you have to remember the essential parts of the transaction, the state,
somehow somewhere. That could be a DB record, that could be a user space,
or whatever. The key for this is sent to the browser and back with the next
request so the CGI can get back the state.

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. But one could take the advantages of the first
one and build an optimized SQL-Update string. When a user only updates the
customers phone number, one shouldn't update the whole record, just the
phone number. And the actual file value should be compared to the state
holder value. If these are not equal, a "replication" conflict is found and
should be solved - by the program or by the user.

I haven't made the above true yet; it's just an idea so far. Is Relational
Web providing such functionality "out of the box" or with functions similar
to those whose simple beauty you already showed us?


best regards /  Mit freundlichen Grüssen

Anton Gombkötö
Avenum Technologie GmbH

http://www.avenum.com



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.