cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [RT] Flowmaps revisited
Date Wed, 07 Nov 2001 15:11:13 GMT


giacomo a écrit :
> 
> 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 :)

Giacomo and Stefano living together for a few days : be prepared for
nice RTs or even more ;)

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

There are two other nice packages for graph drawing :
- JHotDraw at http://jhotdraw.sf.net which is used for a Struts editor
(www.scioworks.com/scioworks_camino.html)
- GEF at http://gef.tigris.org which is the base of ArgoUML.

GEF is more feature-rich than JHotdraw, but the project seems to be
asleep.

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

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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


Mime
View raw message