cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <>
Subject Re: [RT] Flowmaps, propagation, and aspect-oriented data processing
Date Mon, 19 Mar 2001 22:33:21 GMT
Peter Donald wrote:

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

Yes. I think of it like the Control View of the webapp, if your are 
familiar with the data/functional/control views.

I see here:

Data View  --------> content
Functional View ---> the functions are the states
Control View ------> a flowmap (events)

The chalenge in webapp development is, a Stefano pointed, to separate the
link -> resource related
from the
link -> "windowing" event of the app.

This will become much more important when several apps are aggregated 
together. How do I manage a "Check Mail" link^H^H^H^H event without 
perturbing my "quote portlet" in the same page?

I think the key here is to have an abstract representation of the events 
that a container (let us say a windowing desktop, like what Jetspeed 
wants to be) provides, and also a way for a webapp developer/deployer to 
specify the "flow" of the application. I mean things like "minimize" 
(container provided, with hook to the App model) or "check new mail" 
(app specific, but handled by the flowmap).

This will allow, if done properly, to have the same webapp source code 
rendered as WML decks, as HTML, or a an applet handling the XMl data, 
for instance.

I'm using here webmail as an example, as it is a well known example of a 
webapp that would be nice to have as a window in a portal, and provides 
non trivial application events (Control Model).


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

This could be handled by having the system states managed through the 
session. I have seen webapps controlled like this. You could call always 
the same url, with something like ?state=af3d4e meaning "advance the 
state machine to wherever". So, only "legal" transitions would be 
handled by the container. It is tricky to implement if you don't have 
the proper abstractions in the webapp side, though.

Ideally, the webapp would receive event notifications like "the user 
wants to know if there is new mail", or "I have been minimized", and not 

The concept here is to deliver the level of abstraction that a Window 
manager gives us (as a bare minimum), instead of reinventing our window 
manager for each application (like in the old DOS/curses times).


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

View raw message