- A naive question about browser based applications
Hi, I have one little "niggle" regarding browser based application deployment that has been simmering on the back burner for quite a while now. Now that I'm getting ready to get really serious about Zope, et al... I'm now wanting to get this answered. Scenario: Heads down data entry/long session of interactions... Questions: - As I go from screen to screen to screen (ala panel model of non-active, e.g. Java, interaction)... each panel "stacks" on top of the previous, right? - If so, is there any way to force the browser to "flush" the stack, with the side effect, for example, of making the "Back" button on Netscape not return to the screen from whence I just came? For example, if I go "in" 10 levels, I can then go "Back" the 10 levels. If at the 10th level, I did a "commit", and then if I back out some number of levels, and then took a different path, or did something that thought it could do a "transaction abort" or "rollback" (etc), how do I maintain transaction integrity? - If there is no way to "flush" the stack, how do I keep the browser's URL stack from eventually overflowing? Let's say that I expect several hundred, or thousand, or millions, or trillions (USA or other) of transactions in a session... (no matter what limit you set, I'll claim that I need several times that number of interactions... which is easily accomplished in a typical application that doesn't nest...) What I think I want (in effect) is an interaction model, using Zope, that is: while not done: dowork() rather than the stacking of: dowork() dowork() dowork() ... dowork() ... from which I can then "Back", "Back", "Back", "Back", "Back"... all the way out... -- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) -----------------------------------------------------------------------------
On Wed, Jan 13, 1999 at 09:20:11AM -0600, LD Landis wrote:
Hi,
I have one little "niggle" regarding browser based application deployment that has been simmering on the back burner for quite a while now. Now that I'm getting ready to get really serious about Zope, et al... I'm now wanting to get this answered.
One niggling concern? Oh you must not have tried CSS or anything else "interesting"... I've been working with CSS sincei t came out, and I'm nearly bald (well, not quite) as it's half-ass supported partially in each browser, but with different broken pieces, and the overlap between the two is about THIS big.
Questions:
- As I go from screen to screen to screen (ala panel model of non-active, e.g. Java, interaction)... each panel "stacks" on top of the previous, right?
Nope, it's more a linked-list, they're not "stacked". Remember, the web wasn't architected for this model at all, so everything is a kludge.
- If so, is there any way to force the browser to "flush" the stack, with the side effect, for example, of making the "Back" button on Netscape not return to the screen from whence I just came?
The only way to get access to this is through the _history_ object in JavaScript, but... it's no longer public in 4.x, and you can only give it methods like history.back() and not delete things off of it (as you used to be able to do). So no :-)
For example, if I go "in" 10 levels, I can then go "Back" the 10 levels. If at the 10th level, I did a "commit", and then if I back out some number of levels, and then took a different path, or did something that thought it could do a "transaction abort" or "rollback" (etc), how do I maintain transaction integrity?
Well, what EasySABRE does (huge travel reservation system with a web interface to a command line system... it's ugly, but hey...) is to make EVERYTHING a POST against the same CGI, which responds with all the necessary information. If you try and go back, you get a "Repost Form?" question, and if you do, well, it responds tellin you that you can't use the browser's back button.
- If there is no way to "flush" the stack, how do I keep the browser's URL stack from eventually overflowing?
It's not a stack, but a linked list (ok, I'm being niggly myself :-), and it has a predefined size, and things just fall off the end :-)
Let's say that I expect several hundred, or thousand, or millions, or trillions (USA or other) of transactions in a session... (no matter what limit you set, I'll claim that I need several times that number of interactions... which is easily accomplished in a typical application that doesn't nest...)
What I think I want (in effect) is an interaction model, using Zope, that is:
while not done: dowork()
rather than the stacking of:
dowork() dowork() dowork() ... dowork() ...
from which I can then "Back", "Back", "Back", "Back", "Back"... all the way out...
See the comment above about EasySABRE, you can probably accomplish this with a combination of things, but it's going to be VERY VERY complex, I know the people who wrote the EasySABRE interface, and it's 30,000 lines of C-code (mostly for performance, but there's a lot of integrity checking). Chris -- | Christopher Petrilli | petrilli@amber.org
participants (2)
-
Christopher G. Petrilli -
LD Landis