cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject RE: [RT] Flowmaps revisited
Date Wed, 07 Nov 2001 13:40:07 GMT
On Wed, 7 Nov 2001, Torsten Curdt wrote:

> > >> 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.

Yes, definitively. That is what Stefano and I am talking about this
week. We have one eye at Berins proposal from Juli this year and we try
to get the picture of the puzzle :)

>
> [snip]
>
> > 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'm not sure about that statement. We could have a vote on this to get
the feelings of the other commiters if a Cocoon IDE is something that
should be started here or elswhere.

Giacomo

> > 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

>
> http://www.gerwin-klein.de/grace/
>
> > * 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.
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message