cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Flowmaps revisited
Date Mon, 15 Oct 2001 13:30:35 GMT
Sylvain Wallez wrote:

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

Thanks :)

> I love RTs ! This is a part of what makes this project so great : no
> fear to think out loud in the open.

Exactly. Many people do open source. Here, we do "open development"
which, of course, in order to work requires the source to be available
in an truly open way.

Big difference and the results show it.
 
> I'd like to add some thoughts on "flow navigation" without waiting for
> Daniela's description. 

Great, the more ideas to stymulate us, the better the results will be.

> From what I've understood, this concerns the
> automatic analysis of which transitions are possible from a given state.

Yes and it's a good thing indeed: the more the framework does, the less
you have to do :)

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

Ok, good parallel.
 
> 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).

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

Hmmm, very good point.
 
> 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.

Hmmm, not sure I follow you here. Can you elaborate more?
 
> 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 !

Absolutely, there needs to be sort of context-based namespacing in order
to avoid name collisions, but that is a semantic detail and should be
dealt with when discussing the semantics in detail, we are still at a
more general level.
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message