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/).
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
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki