Aida "Flow Control"

Hi Rob,

You make a flow control by jumping between the pages with help of decision in action methods, then using various #redirectTo methods to make a jump. You can jump in other view on the same App or to some view of other domain object.

Note that in the moment of calling the action method all form elements like input fields are already posted to the domain model, so that you can use their values for decisions where to go next in your workflow.

I hope this is the right answer in your case.

IMHO you're doing something wrong, as soon as GUI-related
information like the one you mentioned creep into your model objects.

Models know *nothing* about the environment they're being used in. You
should be able to rip your model classes from your AIDA application and
plug them into a fat client as they are.

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.

On Wed, 28 May 2008 11:51:10 -0400

"Rob Rothwell" <[hidden email]> 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.
_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida

I think here we are talking more about navigation than a workflow. The
navigation down to some domain hierarchy and back. And here is the
problem, how to climb the hierarchy back to the top.

I actually have parent relationships in my domain model so that every
child knows its parent too. That way you can achieve a complete
navigation from domain mode alone, without some special tricks like
remembering where you come from etc. That's why my web apps are full of
navigation support like hierarchical links, left/right buttons to
navigate horizontally, etc. See this page for example:

I don't know much about use of decorator pattern in Seaside either, but
from below explanation I can see similarities to our web elements (aka
components), adding other elements in it, including form elements.

But one big difference comparing to Seaside is that we have only one
form per page. All form elements are recursively registered into that
sole form just before page got rendered into HTML.