cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject RE: [RT] Flowmaps revisited
Date Wed, 07 Nov 2001 11:10:58 GMT
> >> 2) Is it possible to have multiple actions take
> >> place
> >> during the processing of a state?
> >
> >Good question.
> >
> >First, I was tempted to answer with "yes", because I
> >was so used to the
> >current action model of the sitemap, but the longer I
> >think on this, the
> >more I'm convinced that "no" might be the more
> >approriate answer.
> >
> >I think it might result in a much clearer model if we
> > assume that each hidden state is bound to exacly one
> > action. If you need a second action to be executed,
> > this should be done in a seperate state.
> >
> >But I'm not yet sure on this point.
> I've implemented something recently similar to your
> model.  What I've found is that there can easily be an
> *explosion* of transitions, states and hidden states
> for even a modest application.  I haven't had a need
> to chain actions together yet, but it is trivial to
> support and I can think of plenty of instances where
> you'd want to.  My vote would be to allow actions and
> nested actions, but promote a "proper" use where only
> *screenflow* logic is represented in the flowmap;
> business logic should be factored out of the flowmap.

Being so impressed by this idea I implemented something similiar.
I figured out that you have to distinguish between different
_types_ of actions. Maybe this distinction should be forced
for the proper use.

 * transition actions
 * sitemap actions
 * business actions - who are in fact methods of the diff. BOs

(Currently transition + sitemap actions = cocoon actions)

It seems like the implementation of the transition actions can have
a deep impact on the verbosity of the flowmap. I'm not quite sure
if nesting actions is really a good idea. Then you have merge the
results, match them and we will have to sitemap instances one
for the URI space, one for the flow - hm... maybe not that bad at
all. Maybe the same code could be shared... Just an idea...

In general I feel a full implementation of the flowmap (integrated
with the sitemap) might remove most of the actions from the sitemap
which is IMHO is a good thing. (This might bring back one of the goals
for the sitemap "minimum verbosity" and SoC) It then comes back to URI
mapping and will not be abused to build applications.


> As I've mentioned before, there are several things I
> don't like about our current implementation.  You may
> or may not be seeing these same issues.
> * While the number of visible <state> elements is
> manageable (in effect, the flowmap becomes a registry
> of the pages in your app, along with the events they
> can respond to), the number of <transition> elements
> to keep track of gets big very fast.  Especially if
> you have variations on similar paths through the app. 
> Reusing states and transitions within an application
> is not as easy as I expected, but we may be able to
> fix that when we refactor.
> * Manually building a valid flowmap is difficult and
> error prone.  The second app I wrote with the flowmap
> was a flowmap validator that checked the 10 most
> common inconsistencies we'd find with large flowmaps. 
> ;)
> * The complexity of some of the flowmaps we've built
> makes us long for an IDE to lay out the app (or
> perhaps a web app under Cocoon to manage flowmaps). 
> Although I don't think the Cocoon crowd is up for
> distributing a drag-and-drop flowmap IDE with Cocoon,

Why not having a sourceforge project first...

> I think it's going to be necessary.  We might consider
> the new Eclipse open framework IBM is pushing.

That's true! I've had a look into "grace" for this

> * The other confusing thing for developers and users
> is that because we took the tip to "always post back
> to the page that generated you", the URL in the
> browser window shows the page you came from, not the
> page you're on, and the hover status in the status bar
> doesn't give the right visual feedback about what's
> going to happen.  I guess we could do something with a
> redirect instead of generating the page the
> flow-handler tells us to, but I haven't tried that. 

No!! Using http redirects for flow is bad thing. This
will involve another request!!

> (Does anyone know if the sitemap "redirect" map
> element does a complete redirect roundtrip to the
> client, or does it short circuit and just redirect
> within the context of the open request???)

Short circuit would keep the URL in the browser window
so I am pretty sure it a roundtrip to the client.

To unsubscribe, e-mail:
For additional commands, email:

View raw message