Tree-like control flow

Bits from conversations on our #aida IRC channel:

What do you mean by tree-like control flow?

If you are writing GUI like web apps, you'll have a problem.  But we will address soon GUI like web app part too, to close that gap. GUI apps has mostly a tree like control flow, while the web is not such. Seaside is therefore good for such kind of web apps but most of web apps/systems are not such. The web is inherently a graph like structure, not tree like, so if you use tree like control flow for the web, you are limiting yourself a lot.

On the other hand the tree like control flow is necessary for some stuff and doable in current Aida too, but not so easy as in Seaside. So we will add this functionality to Aida as well,  but without breaking the main Aida strength: to support the real, pure web apps really good.

In structured programing you have tree-like control flow: you call one object, that one calls another, then returns a result, then call another etc.  If you graph that, you'll get a tree.  All structured languages also use a stack, which is essential for the tree-like control flow.

But the web is not a tree like structure, but it is a directed graph. You are free to go from any page to any other, not just down to one and then back to go to another. You can also circle indefinitely on the web, for instance, while you cannot circle indefinitely on tree-like structures, you'll end up in indefinite recursion and end of memory.

Aida is designed for graph like control flow, while Seaside is just for tree like, which is in essence its main drawback.

Solution for the tree-like control flow?

Simple, with standard Smalltalk processes, no need of continuations or similar tricks,  no need even for call: answer: methods

Example:

confirmation dialog in #actionDelete

    self ask: 'Do you really want to delete?' 
         ifTrue: [sellf observee delete].

ask will popup a yes/no dialog and return a boolean

no need of call: , and answer: in ask method

This can be achieved with forking another process while calling #ask: while this process is put on wait on semaphore.  After the popup yes/no dialog posts a result, the forked process signals the semaphore and original process continue.

Processes are supported in all smalltalks, you don't need to change therefore their VMs to support your web framework.

What about several popup dialogs?

do you want do to this? yes  are you really sure? no

You just produce a chain of such processes, which kind of simulate calling stack.

Implementation

This all will be controlled with a new class called WebContext,  and in case of stacked modal windows you'll have a chain of WebContexts. All active WebContexts will be stored in WebApplication.