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 21:08:34 GMT
On Wed, 7 Nov 2001, Sylvain Wallez wrote:

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

Hey, don't expect too much. There are old sins to be atone ;) (like the
label attribute which is giving me some implememntation headaches
because of XSLT).

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


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


Mime
View raw message