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 Sun, 14 Oct 2001 09:39:34 GMT


Stefano Mazzocchi a écrit :
> 
> Daniela Gehle wrote:
> 
> > Correct. We've made exactly this experience when developing a small
> > application a few weeks ago, and we all were (or at least, most of us were
> > :-) very unhappy with the first implementation which mixed flow instructions
> > (i.e. target resources) into program logic (i.e. actions).
> >
> > That was the reason for us to go a step back and think about a clearer
> > separation of concerns in a more elegant concept. And that's where the
> > Flowmap jumps onto the scene.
> 
> I think that more or less every cocoon user will hit that wall, yes. So,
> we must have plans on how to remove that wall before too much people run
> into it and get hurt.

Seems that many cocoon users already hit it, hence the large interest
for this subject :)
I'm also really interested in flowmaps, and want to thank Daniela for
her great proposal.

<snip/>

> So, the atom of state transition for the web using visible and invisible
> states can be pictured as something like this:

Aha, this time it's sure, Stefano is really back ;)
I love RTs ! This is a part of what makes this project so great : no
fear to think out loud in the open.

<snip/>

> > > > I don't want to confuse you - so I will touch this mechanism only
> > > > marginally within this presentation, but in fact it is an important
> > > > requirement that had fundamental influence on the presented design. If
> > > > you are interested, let me know, and I will feed you with additional
> > > > details.
> > >
> > > Please do.
> >
> > Sure. :) I'm going to post a more detailed description asap. (Hopefully
> > today or tomorrow, I'm kind of torn between several projects at the moment,
> > so please excuse if my response time isn't perfectly short...)
> 
> No problem.

I'd like to add some thoughts on "flow navigation" without waiting for
Daniela's description. From what I've understood, this concerns the
automatic analysis of which transitions are possible from a given state.
There come two requirements for a useful system : transition
authorization and transition classification.

Transition authorization :
------------------------
In all desktop-based applications, tool bars and menus expose the
actions available to the user, but some of them are deactivated. Such
deactivated actions represent possible transitions (described in a
flowmap), but which aren't currently available because the application
context doesn't allow them. Many things in the context can lead a
transition to be unavailable. Some examples : user isn't in the right
group, current selection doesn't allow a given action, subsystem
temporarily unavailable, etc.

Such restrictions could be represented explicitly in the flowmap, but
would lead to an over-complexified graph where each possible combination
is handled separately and wouldn't allow the display of transitions that
are disabled because of the context (either as greyed buttons or
non-linked text).

The solution here can be the use of boolean selectors that filter events
in the "states" element :
<state name="display-data">
  <select type="someDataSelected">
    <if event="DELETE" transition="DELETE"/>
  </select>
  ...
</state>

This also allows to solve some of the secutity issues related to
stateless HTTP. Event selectors are tested twice : once for displaying
the page associated to the state, and once when handling the request.
Thus someone cannot manually build the URL that fires "DELETE" if the
system doesn't allow it.

Transition classification :
-------------------------
Once we have a mean to automatically build a list of available
transitions from the current state, we can define generic presentation
templates to layout them on the page. But a page has several areas where
transitions can be displayed, so we need to be able to classify
transitions to be able to dispatch them in the adequate area. This is
where subflowmap can be very useful : it seems to me that we can
consider that each transition display area contains either the list of
available transitions in a single functional area, or lists the entry
points to separate functional areas.

So we could consider that functional areas of the application should be
organized in hierarchical flowmaps. A navigation menu is then the list
of available transitions of the top-level flowmap, and buttons like
"validate" and "next" are the list of the available transitions of the
lowest-level flowmap. Just like top-level menus, sub-menus can be the
list of transitions of intermediate-level flowmaps.

<snip/>

> > > > --------------------------------------------------------
> > > > The Transition Map
> > > > --------------------------------------------------------
> > > > <flow start="login" name="search-archive">
> > > > <transitions>
> > > >   <transition name="AUTH" target-state="check-login">
> > > >     <parameters>
> > > >       <parameter name="username" xpath="/environment/user"/>
> > > >       <parameter name="password" xpath="/environment/pass"/>
> > > >     </parameters>
> > > >   </transition>
> > >
> > > Shouldn't a transition be described by two states, the target *and* the
> > > originating point? Maybe not, but this may generate collisions.
> >
> > I don't think so.
> >
> > A big advantage if you don't specify the originating point is that you can
> > "reuse" transitions. For example: you can use the "LOGOUT" transition from
> > any desired page. If the description of the transition contained the
> > originating state, you would need to specify n LOGOUT transitions, one for
> > each originating page, all with a different name, but the same parameter set
> > and all with the same target. And I don't suppose that that's what you want.
> > :)
> 
> Good point. :)
> 
> > Our first design kept the <transitions> enclosed in the <state> element,
but
> > after some reflection we found that it is much more elegant to separate the
> > <transitions> from the <states> in order to reuse them and to avoid
> > redundancy.
> 
> Sounds very declerative to me: good choice.

Yes, but this enforces the need to have subflowmaps, otherwhise naming
transitions with unique names throughout the whole system will be a
headache !

> I'm going to try to come up with an example statemap and then we can
> work on that. If anybody else wants to do it, he/she will be very
> welcome to do so. The more ideas thrown in, the better.
> 
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche

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