How the control flow is passed from Pier to Pontoon

Hi, This is a follow up to a current discussion within the *Seaside-dev* mailing list, with the goal of clarifying how the control flow of Seaside, caught by Pier, is passed to Pontoon. Just to situate the context, let me add that Pontoon is the name of a framework under development for implementing by reuse and extension web applications with integrated on-line flow modeling and execution functionality. It heavily draws of community work on Smalltalk, Seaside, and Pier, that I'd like to take the opportunity to thank for the quality of their work, and as a community as a whole. Pontoon uses Pier in several ways. I'll progressively communicate more on that. The one which is of interest here, is the Pier extension to Seaside's Request handling, that specifically comes with a remarkable mechanism for handling Contexts, as, roughly speaking, associations of structures and commands. To keep the design and implementation as consistent as possible with Pier, while ensuring the execution of on-line defined flow models, Pontoon parallels the #execute protocol of PRCommands, and typically catches the control as follows: - WAActionPhaseContinuation >> handleRequest - WAActionPhaseContinuation >> runCallbacks - PRPierFrame >> update - PRContentsWidget >> onChangeContext: - AAsFlowModel >> execute The *trick* consists simply in creating PRContexts that point to Pontoon flow models, instead of Pier Commands. Once a Pontoon flow model takes the control, it determines how it further flows. Given that flow models may be defined on-line, this means that end-users may determine themselves the rules that underlay that flow. In other terms, the flow of control for the behavior that users are concerned about is not necessarily *hard coded*. This is specifically useful when: - The control flow can only be known at runtime (with applications, for example, to support daily life activities), and - The control flow is subject to frequent changes in time and space whilst the web application is already deployed (for examples of application domains, please see <http://adaptiveobjectmodel.com/>http://adaptiveobjectmodel.com/). Pontoon flow models implement their own specific #execute logic, which includes handling concurrent execution, persistency, atomic execution, and exceptions, while remaining consistent with those of Pier, and reusing them whenever possible. As *meta-described composite commands*, flow models may #call: Seaside components. This allows end-users defining on-line their own models of interaction among a set of *primitive* software services, including Seaside components. As soon as the issue we are discussing on *Seaside-dev* is addressed, I'll set-up a demo web site, and post the url here. Regards, Reza