cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [RT] Flowmaps, propagation, and aspect-oriented data processing
Date Fri, 16 Mar 2001 04:00:30 GMT
At 03:09  16/3/01 -0000, Robin Green wrote:
>2. One advantage of flowmaps (see foot of email for a copy of Stefano's 
>definition of flowmaps) that hasn't yet been mentioned is autopropagation to 
>further reduce redundancy - although perhaps this is only useful for a few 
>concerns, like authorisation.

I would say it is more generally if you think outside the square ;)

Consider the flowmap as a state transition diagram. Associated with each
state is required (and optional) input and associated output (ie output
which will be stored when certain transitions are taken).  

So if we have base admin stage - it's required data elements may be
* admin-token
* username

For a complex multi-form setup the last stage may require 
* formfield 1-20
* formfield 21-40
* admin-token
* username

In essence this is the M part of MVC. Currently all web-based systems I am
aware of represent M implicitly rather than explictly. 

So I would say that all of M is propogated to next state when a transition
occurs unless it is explicitly consumed by application. Propogation can
thus occur for any data that the developer is willing to consider from
user-transactions to database transactions to webapp data etc.

In a really good system it would even be possible to specify constraints
for particular items in M. 

So you could say that 
* admin-token.level > 5
* isPrincipleInRole( username, "my-special-role" )
* isValidEmailAddress( formfield 22 )

implicit Authorisation checking via actions (what you specify) is a
simplification of this model.

>Definition 1: the propagated constraint of a state S (which I'm considering 
>here to be equivalent to a resource - see below) is [the logical-OR of the 
>propagated constraints on each of the directly backlinked states] 
>logical-AND the explicitly specified constraint for S (the latter is taken 
>to be just 'true' if no constraint is specified).

Seems reasonable. But I would still consider a 
state = resource (and associated parameters) + input defintion + output

>Definition 3: The constraint on (start) is simply 'true', i.e. no 

I am not sure this is neccesary. For instance you could have a site that
only allows users from 131.172.242.* to access the site and thus the start
constraint would be that.
>To change the site design to make a certain subnet of the flowmap 
>"admin-only", we just move links to the "entry points" of that subnet to the 
>admin main menu in the flowmap. Both the menu and the security checks are 
>automatically regenerated. (Automagically maintaining the association 
>between links and any corresponding menu images when a link is moved from 
>one page to another is left as an exercise for the reader.) No URI 
>rewriting, not a single line of sitemap editing - not even any content, 
>logic or style editing to alter the menu!

that would be nice - just tried to do the same in vanilla stylebook/xsl and
it wasn't pretty ;)

>Unfortunately the example given here is a bit contrived and does not 
>necessarily provide _much_ advantage over 2.2 (grouping) in terms of 
>separating out security, for many typical sites. More thought needed here.

The question arises that why does a state that is not "exported" have to
have a URI at all? If you can't access a resource directly except by going
through the sitemap then I can't see a valid reason for assigning the state

>3.1. Hierarchical (or even non-hierarchical) menu systems. You might want a 
>sidebar always displaying a context-sensitive menubar, for example, but it's 
>a bad idea to redundantly place a submenu in every file in a directory, 
>obviously. You can use some form of including, but one file per menu means 
>menu files scattered all over, and one big menu file is better, but if you 
>already have a graphical flowmap editor it makes sense to use this to edit 
>menus rather than reinventing the wheel. (Hmmm, weak justification!)
>3.2. Drag and drop a subnet to a new part of the flowmap, and it 
>automatically picks up the "look-and-feel" of its new parent by propagation, 
>even if the subnet is implemented by a diverse set of pipelines! Of course, 
>this is just a sketchy idea without an implementation, and embodies several 
>big assumptions - that "branding" can be done with a cleanly separated 
>stylesheet and/or transformer added on to the pipeline, for example. In some 
>simple cases it could be, but not in others. You also need a different 
>definition of propagation because "look-and-feels" are not boolean 
>functions, unlike constraints!

I would kill for both of those functions ! ;)



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

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

View raw message