[Zope] - A naive question about browser based applications

[Christopher G. Petrilli]

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