|
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 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.