cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniela Gehle <>
Subject Re: [RT] Flowmaps revisited
Date Thu, 11 Oct 2001 16:56:24 GMT
Hi Stefano,

> Dear Daniela, welcome aboard the magic wonders of Cocoon RT series :)

yeah, these RTs are something special indeed. And thanks a lot for the warm
welcome. :)
> I believe that almost everybody working on web applications (even the
> most simple ones) have the same problems of publishing resources
> (states) and controlling the flow between them (transitions).
> In fact, as you write below, a webapp can (and should!) be seen as a
> finite state machine. The problem with currently available technologies
> (even most advanced webapp frameworks developped by the ASF) is that the
> information that "programs" the FSM (finite state machine) is built-in
> into the programming layer. While I agree there is room for people to
> like this approach, I don't and I'd like the FSM instructions *not* to
> be part of the programming logic itself, but part of configurations that
> drive the framework.

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.
> This follows the same pattern that saw Cocoon1 being hard to manage
> because pipeline instructions were written inside documents and not
> outside of them.
> So, just like PI that dynamically assembled pipelines in reactors were
> cool on paper but turned out to be impractical compared to a centralized
> approach like the sitemap, I believe the exact same can be said for FSM
> instructions.
> So, I'm fully convinced that in order to enforce separation of concerns,
> programming logic, documents and other component resources should *NOT*
> contain information on states nor their transitions, not how to compose
> them.

> This information, the very heart of the web application, the blue-prints
> to build it and manage it, should be found elsewhere.
> This will finally give a "global" view of what a web application does
> and how it does it in all places both in the publishing of each state

Which, if sticking to my notation, would be "... each _visible_ state...". 

> and in the operation performed during transition between one state and
> another.

And again: "... between one _visible_ state and another." And the operations
would be performed in the hidden states. But that's nitpicking. :)
> > We've been reading and discussing your
> > proposed approaches carefully and found valuable inspiration in it.
> Same here :)


> [...]
> > This approach is "lighter" in the sense that it can easily be integrated
> > into the current Cocoon 2 framework using the actors concept.
> Personally, I believe that global elagance has higher priority than
> instant integration with existing solutions. Not that I don't care about
> back portability, rather the opposite in face: I believe that a well
> thought-out and designed technology is much more likely to remain
> untouched once all the details are considered globally, rather than
> incrementally.
> Adding flowmap capacities to the existing sitemap might be possible, but
> might sacrifice elegance and ease of use and I wouldn't want that at
> this point.

I understand your point perfectly. I personally don't like unelegant
solutions, too. But there is ONE problem: we need that stuff pretty soon
now. If you think that it's likely that the sitemap redesign and
reimplementation will be in place within a few weeks, this is a solution we
could perfectly live with. But it would be really inconvenient to lose more
time on that. And exactly that was the reason why we came up with this
"fit-in-both-concepts" design approach.

Do you have already anything particular in mind concerning the sitemap
restructuring and the flowmap stuff? 

Do you suspect any specific collisions and problems?

> [...]
> I'd love to welcome you guys aboard and I think we'll all be happy to
> invite you to join us in our effort toward the same goals.

Thanks, we'll do our very best. :-)

> > [...]
> >
> > - navigation that refers to states in a flow and grants access to a
> > subset of pages that are part of a flow. We call this type of navigation
> > "flow navigation" from now on.
> >
> > Static navigation is a pretty simple issue, so we will concentrate on
> > flow navigation in this article. As a special aspect of the flow control
> > presented here, the approach provides a mechanism to generate these
> > "flow navigation" elements automatically from the state description in
> > the Transition Map. As far as I know, this is a topic that has never
> > been addressed on the Cocoon list before.
> Not really, but sure not in such a great detail.
> Berin and I already expressed the intention to have the possibility to
> navigate to abstract states that do not represent a real resource. Such
> as the "next" target after you completed a form, or something like that.
> This is probably part of what you call "flow navigation".... hmmm, have
> to think more about this...

Ahh, I see.... Seems I didn't express myself clear enough on that point.

Flow navigation does not mean how to navigate between states of a flow in

Flow navigation means placing URLs/links on HTML/WML/... pages, with the

- that these links lead to other states of the flow, 
- that these links can carry additional parameters and
- these links are generated automatically from the Transition Map
- specifically for the current page.
> > 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...)

> > [...]
> >
> > The main processing direction is forward, but a backward navigation to
> > any of the previous pages has to be supported as well. If you are
> > currently looking at a newspaper article (article-display page), you
> > might want to jump to the page where you can change the selection of the
> > topic (topic-selection page). Or you might want to change your password
> > from any of the pages - this means that access to a "change-password"
> > page must be possible from every page.
> Yes and good usability will place even more navigation complexity even
> for those static navigation resources. (to be honest, I tend to believe
> a good site will almost never have static navigation for usability
> reasons, but I might be wrong)

In my opinion, this depends to a great extent on the purpose of the site. If
it's just an information publishing site, you can be perfectly happy with
static navigation. At least that's what everyone is used to and what
everyone expects from a static navigation on a web site. 

But as soon as even the smallest controlled flow comes into action, you're
lost and you will need something else to support the navigation within the

> > This shows us that the flow is NOT just a simple sequence of pages
> > processed in a row, but of a much more complex structure (which is not
> > really easy to draw in ASCII graphics and therefore be omitted here :-).
> Yes, I've already drawn these pictures on my whiteboard before and I
> know what you mean. In fact, one of my feature-dreams is to be able to
> draw a nice SVG poster of such complex FSM graph directly transforming
> sitemap/flowmap information. But that is future stuff :)

Sounds futuristic indeed. :)

> > Moreover, we have been cheating a little bit so far. The flow consists
> > not only of pages - representing visible states of the system
> > (accessible via an URL) - but also of hidden states where system
> > operations are performed (like data verification or query processing).
> > These hidden states can lead to visible states or to other hidden
> > states.
> Uh, this is what was left on my picture. Hmmmm, very interesting....
> very interesting...
> > Therefore, the login sequence of the above mentioned page flow should
> > better be written like this:
> >
> > login --(AUTH)--> [check-login] --(AUTH-OK)--> topic-selection ->..
> > login <--(AUTH-NOT-OK)--|
> >
> > Please note that in this notation the transitions themselves have unique
> > names like (AUTH) or (AUTH-OK), and the hidden state [check-login] is
> > marked with square brackets to illustrate the difference to   visible
> > states. As its name proposes, the [check-login] state verifies and
> > processes the data entered in the login form on the login page.
> I love this! 

Fine. :) In fact, after coming up with the clear separation of visible and
hidden states and naming transitions, everyone of us was somehow struck as
well, because this model seemed the first to be "clean" and all the ugly
tricks we had to use in our former models vanished in an instant.

> > Now we can put together a description of all states and all transitions
> > in a Transition Map:
> >
> > --------------------------------------------------------
> > 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.

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

Maybe the transition should NOT even contain the target state to make them
even more reusable. Transition would just be a named set of parameters then.
But I'm not sure... This might lead to unwanted collisions.
> > [...]
> > 
> > It might be possible for a visible state to contain a handler
> > as well, but this is not recommended, because then the clean separation
> > of visible and hidden states would be broken.
> Agreed. I like this separation very much. In fact, I never liked the
> action proposal in the sitemap since the granularity of reusability of
> actors is visibly different from that of sitemap components.
> But in flowmaps, actors really shine.

So you're thinking of removing the actors from the sitemap and permit them
just in the flowmap itself?
> > The decision which of the possible transitions to follow at a specific
> > point is done by evaluating the transition event parameters. These
> > parameters are either URL parameters (in the case of a visible state) or
> > result parameters of an action (in the case of a hidden state). Event
> > parameters are written in Capitals in order easily distinguish them from
> > ordinary parameters.
> Or might be otherwise namespaced, but I think this is just an
> implementation detail.

Right. The Capitals were just invented to ease reading.
> > --------------------------------------------------------
> > Sitemap configuration: the FlowHandlerAction
> > --------------------------------------------------------
> > In order to control the flow and the state transitions there is a
> > FlowHandlerAction hooked up in the Sitemap.
> This is what I don't like that much. I think flowmaps are important
> enough to require a more specific hook-up semantics and the action
> framework might allow this, but maybe there are more elegant solutions.
> (I'm picky, I know)

Well, then let's hear what you'd prefer. :)
> > More precisely, the
> > FlowHandlerAction will be performed for each URL that is representing a
> > (visible) state in the flow.  The FlowHandlerAction has to be fed with
> > the name of the flow for each pattern match within a flow.
> >
> > The Sitemap contains something like
> >
> > <map:match pattern="in-the-flow/*">
> >   <map:act type="FlowHandler">
> >     <map:parameter name="search-archive"/>
> >   </map:act>
> >   <map:act type="AuthenticationAction">
> >     <map:redirect-to uri="in-the-flow/login"/>
> >   </map:act>
> >   <map:generate type="saxlet" src="templates/{1}.xml"/>
> >   <map:transform src="styles/{1}.xsl"/>
> >   <map:serialize/>
> > </map:match>
> >
> > The Transition Map file itself will be specified within the definition
> > section of the FlowHandlerAction:
> >
> > <map:actions>
> >   <map:action name="FlowHandler" src="">
> >     <map-file>transitionmap.xmap</map-file>
> >   </map:action>
> > </map:actions>
> This is exactly the inelegance I was talking about: sounds like an hack
> to me.

It IS a hack, of course. ;)

> Let's work out a specific semantic addition for flowmaps.

Agreed, this would be much better. Any ideas?

> > --------------------------------------------------------
> > Are all the promised features there?
> > --------------------------------------------------------
> > (1) Controlling the flow (i.e. state transitions) of the application? -
> > Yes.
> >
> > (2) Separation of data processing ("control" aspect of the MVC pattern)
> > and data generation ("view" aspect of the MVC pattern)?
> >
> > Yes. Control is performed by the handlers of the hidden states, data
> > generation is performed by the specific Generator (ServerPagesGenerator,
> > SAXLet Generator,...) for each page representing a visible state.
> >
> > (3) User authentication and authorization?
> >
> > Yes. Except for the login process itself which is performed by the
> > LoginAction Handler of the "check-login" state, user authentication and
> > authorization are located in the AuthenticationAction used in the
> > Sitemap. Please note that this is one of the main differences to Berin's
> > proposal, were an authorization mechanism was part of the flowmap
> > itself. We decided to put the authentication and authorization aspects
> > apart, because not all applications rely on the same consistent
> > authentication/authorization mechanism. Therefore, in order to be open
> > to any authentication/authorization requirements, it seemed to make more
> > sense to  place them in actors called from within the Sitemap or the
> > Transition Map. Of course, a combination of both approaches is perfectly
> > possible.
> I think we must elaborate more on this, but I want more feedback before
> stating something on this topic since I'm not really an expert on this.
> > (4) Jumping to any visible state in the middle of the flow in one hop?
> >
> > Yes. This is possible, provided that the necessary ordinary and event
> > parameters for the march along the transitions leading to the desired
> > target state are passed along with the HTTP request. As long as the
> > required parameters for the transitions between the states are contained
> > in the URL, the state machine will jump from state to state without
> > bothering the user with displaying pages belonging to intermediate
> > states.
> > For example: If you want to jump to the state "search-form" without
> > crossing the "login" page, you can enter the URL:
> >
> > Starting from the "login" state the subsequent states "check-login",
> > "topic-selection" and "find-topic" are automatically crossed, leading to
> > the target state "search-form" (and displaying the "search-form" page to
> > the user).
> Or even have a sitemap matcher retokenize your encoded URI to come up
> with that information. A great thing would be to automatically provide a
> form with all the fields already complete but those missing or invalid.
> So, for example the password doesn't need to be explicitly written in
> the URI but everything else.

Futuristic, but cool ideas again. :) 
> > (5) Automatic generation of "flow navigation" elements for each page?
> >
> > Yes. This task will be performed by a specialized FlowNavigation
> > transformer using the xpath attributes of the transition descriptions in
> > the  Transition Map, matching them against XML elements of the generated
> > data and inserting generic "flow navigation" controls in the XML data
> > that is being processed.
> Hmmm, this might lead to concern overlap so we must be careful, but in
> general, I see some great value on this.

Concern overlap in what respect?
> > (6) Handle form submits?
> >
> > Yes. Default target of a form submit is always the current page (=state)
> > itself.
> YES! This is a conclusion that I drew as well.

Fine. :)
> > The FlowHandlerAction checks if there's an event parameter
> > triggering a transition leading to another state (according to the state
> > and transition description in the Transition Map) or if there is no
> > matching event parameter and the page itself has to be generated.
> >
> > (7) Support generation of forms?
> >
> > Yes, this is possible in combination with flows, but not implemented
> > yet. Using a form descriptor similar to the <parameters> element of the
> > transition description in the Transition Map, forms can be generated in
> > a unified way, with the default form submit target being the current
> > page.
> This should definately work closer with Berin's project on XForm.

Sure. It's important to design the stuff in an open and general way and to
tune it so that it works together with other components smoothly.

> Probably he'll have more things to say on this.

Probably we'll have more things to say as well. :) We're working on a form
handling and validation component as well, and we'll be ready to present the
concept on this list soon. But this might take a few more days, as the work
is still in progress and the developer who's responsible for this component
is currently on holiday... 

> [...]
> I think you also considered a high priority to use the existing
> framework without changing things, but I repeat that I'd like to shoot
> for elegance at this point than back compatibility, expecially for such
> an important thing.
> So, good job, welcome aboard and let's keep beating the iron.

Yepp! It's your turn again now. :)


To unsubscribe, e-mail:
For additional commands, email:

View raw message