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 Fri, 12 Oct 2001 15:18:39 GMT
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.
 
> > 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...".

Uh, picky girl, I love it :)
 
> > 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. :)

No, you are right: the dual concept of visible/invisible states is the
true architectural advancement.

In fact, I thought that even "hyperlinking" can be seen as a particular
transition between states where the invisible state performs the null
action and has only two connections.

So, a link between resource A and B can be pictured as

 [A] ---> (link) ---> [B]

where [] are visible states and () invisible ones (I like this notation,
is very simple but very expressive). The invisible state doesn't perform
any "routing" for hyperlinks, but might do for, say, login forms

 [login] ----> (validate) -{valid}-> [next]
    ^               | 
    |           {invalid}
    |               |
    +---------------+

where, the notation adds the curly braces that represents the route
name.

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

   +---------------{loop}--------------+
   |                                   ^
   v                                   | 
  [A] ----> (action1) ---------------->+
   |            |                      |
   |            +------{1}-----> [R11] |
   |            |                      |
   |            +------{2}-----> [R12] |
   |           ...                     |
   |            +------{n}-----> [R1n] |
   |                                   |
   +------> (action2) ---------------->+
   |            |                      |
   |            +------{1}-----> [R21] |
   |            |                      |
   |            +------{2}-----> [R22] |
   |           ...                     |
   |            +------{n}-----> [R2n] |
  ...                                  |
   +------> (actionm) ---------------->+
                |
                +------{1}-----> [Rm2]
                |
                +------{2}-----> [Rm2]
               ...
                +------{n}-----> [Rmn]
   
and I believe that *all* web sites can be modelled by attaching one
transition atom to the next.

The resulting graph is, in theory, very complex, but it's pretty rare
that visible state connects to more than one "complex" invisible state.

So, the flowmap must be semantically capable of expressing the above
"transition atom", as well as allowing different flowmaps to be
componentized.

How? well, allowing states to be "hookable". Say, for example, that you
have a login webapp that you want to share between different webapps
that require authentication.

The state diagram

 [login] -> (validate) -> [valid]

should allow sub-flowmaps to say that one of their states should
"inherit" the functionality of the state "valid", so

 flowmap A states:  [login] -> (validate) -> [valid]

 flowmap B states:  [search] -> (check form) -> [results]

 global flowmap states: [B:search] := [A:valid] 

then the two can be used glued together.

This would be pretty damn cool, wouldn't it?

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

Ok, that wasn't clear in your first mail but it is now. I understand.
 
> Do you have already anything particular in mind concerning the sitemap
> restructuring and the flowmap stuff?

No, nothing in particular, I'm still coming from a very global
abstraction view, I'm not ready to dive into semantics until the
complete picture is presented and I'd like to throw more ideas around
and see where they land and what they spark in other people's minds.

> Do you suspect any specific collisions and problems?

I have the feeling (nothing rational but I've learned to listen to those
things) that the difficult point is establishing separation of concerns
between sitemaps and flowmaps.

In fact, with the global vision above, the sitemap is just a piece of
the more general "statemap" of the finite state machine and it's going
to require major contract establishment to be able to separate state
transitions (flowmap?) from state descriptions (sitemap?)

Thus the feeling that the sitemap is, in fact, a very specific
"statemap" but with an implicit flowmap where each transition is, in
fact, a simple hyperlink.

With this vision, it is easy to understand why I see your proposal as
dangerous: you are adding flow information to the existing sitemap and
this might cut the concerns in the wrong place, creating crosscutting
concerns between the two files and forcing regular updates to happen in
both files.

Thinking at a way more general "statemap" which contains both the
sitemap semantics AND the proposed flowmap capacity of describing state
transitions and the parameters associated with the routing choice will
result, later on, in a better separation on concerns on all the files
involved in describing this information.

I don't know, at this point, if one cascaded schema is required or if
one defines pipelines in different files then references the pipelines
by name, or whatever other mechanism to make it easier to edit those
files by hand and reuse them as much as possible without mixing concerns
and forcing multiple updates.

But, at this point, it doesn't (yet) matter: we must come up with a
global and complete architectural vision, then cut it in different
orthogonal concerns and at the end come up with the semantics that
describes it.
 
Of course, I'm talking about the perfect choice here, if you people want
to add it first as a proof of concept, I won't be the one to stop you.

> > 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
> general.
> 
> Flow navigation means placing URLs/links on HTML/WML/... pages, with the
> specialty
> 
> - 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
> description
> - specifically for the current page.

Hmmm, I think we need to think more generally than this if we want to
come up with something that can truly stand the tons of features people
will ask for. :)
 
> > > 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.
 
[...]

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

Exactly! :) This is why I search for global visions and good
architectures: when you find it, you know it by heart and I have the
feeling this is one major step forward in the right direction.
 
> > > 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.
> :)

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.

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

Ok.
 
> > > [...]
> > >
> > > 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?

I'd love to see that. Actors are turning the sitemap into a programming
language and it's not what I'd like to happen.

But we need more thoughts on this.
 
> > > 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. :)

As I said, I'd love to see one global description (even one single file
would work for now) of the site statemap, including visible state
description (resources), invisible state description (actions) and state
transitions (flows).

I know it's going to be a huge file, but then we'll know how to separate
it in pieces as we did with the subsitemap concept *after* the sitemap
was created.
 
> > > 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="org.bar.foo.FlowHandlerAction">
> > >     <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?

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



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


Mime
View raw message