[aida] Aida "Flow Control"

[Stefan Schmiedl]

On Wed, 28 May 2008 11:51:10 -0400
"Rob Rothwell" <r.j.rothwell at gmail.com> wrote:

> The "correct" (again IMO) way to handle this would be to decorate your
> > application model with adapters, which in turn provide capabilities for
> > keeping track of workflow and stuff.
> >
> 
> This is where I get a little lost theoretically--I'm not exactly sure what
> "decoration with adapters" is per se...are there any reasonably "simple"
> classes in a standard Squeak image that I could take a look at to understand
> this better?

I don't know my way around Squeak image, it's been too long since I last
played with it. I'm quite impressed with the way decorations work in
Seaside, but again, I'm currently not deep enough in AIDA to know if a
similar approach would work here. I'm sure Janko can help us out with
this.


Warning: Seaside terminology below.

My typical editor component only deals with the form fields
corresponding to the aspects of the model. The "submit" and "cancel"
buttons and the HTML form are added by the component's caller via
a decoration, called "asForm". Another decoration, "asWindow", provides
a window-like titlebar and border. A third decoration "expiringAfter:"
inserts a meta-refresh into the HTML header to automatically redirect
to the main page.

All of these decorations are applied as the wrapping component sees fit.

So if I have a compound model like a "User" managing an Account object
(username, password) and an Address object (contact info), the wrapping
component decides whether to present the two aspects as two distinct
forms (with two submit/cancel button pairs) or maybe use only one of
them at a time to keep the page simple.

But I can also combine the two editors EditorForAccount and
EditorForAddress into a single form and display them in a single large
"editor window" within the rendered page.

It's only up to me, the caller, to decide this, the decorated
component editors don't know or even care about all of this. They only
render the old data and store the current data.

This is (for me) the "why" behind decorators. As to the "how":

A component stores its "chain of decorators" and calls only the
outermost decoration for handling requests and responses. This
decoration is then responsible for calling its owner, which is
repeated until you finally end up rendering the basic component or you
decide to not call "deeper" stuff.

s.