cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [RT] from linkmaps to flowmaps
Date Tue, 06 Mar 2001 14:09:32 GMT

kewl RT ;)

It is very similar to something I designed in November but never got around
to implementing. So it may be interesting to have another perspective. A
few points;

* I was primarily interested in interactive applications. (ie
WebApplications as well as heavyweight desktop GUI apps).
* What Cocoon terms sitemap - I term ResourceMap++
* I did not want to limit myself to any one format (ie xml/ascii/other).

So using your terminology;

* problem space is a hypercube
* aspects are planes through the hypercube

I would also like to make the distinction that simple aspects are
orthoganal to other simple aspects while complex aspects cross the simple
aspects of the system. 

Cocoons sitemap (hyper???) projects a complex plane (ie made up of many
aspects) onto the URI (naming) plane/aspect.

To avoid conflicts with names I use and names cocoon uses I am going to
adopt the name ContentMap (CMAP) for my version of the flowmap/link/site map.

Terminology aside lets get down to the grit ;)

Like all good designers when I was desiging the app I used the time honored
techniques of analysis/design. First I did object diagrams, state diagrams,
petri nets, flow of interaction diagrams etc. This of course led me
nowhere. The only decent analysis of the system was flow of interaction
diagrams (much like your flow maps but originated in heavyweight GUI
developer space).

I was also looking at C2s notion of sitemap simultaneously and realized it
also similar limitations. ie It designates structural design of a "site".
However often to change interaction (primarily what a "site" is about)
required massive changes in structure. I have had to do this in other
frameworks before (namely turbine) and know what an absolute PITA this is -
it imposes high concentration and high workloads on both UI guys and
So the system I wanted to design was to take in functional/usability
concerns and make it paramount as that is where largest investment of
resources is when developing such things.

Given this I decided I would formalize the flow of interaction diagram into
a state transition diagram. A state transition diagram has states (nodes)
and transitions (arcs). It is only possible for one state to be active at
any time and to change states you need to follow an arc. Associated with
each arc is a set of conditions that must be satisfied for transition to
occur. Simple stuff.

In my design each state had a arbitrary name/identifier. Each state was
associated when concretely expressed would be manifested as a resource (or
a set of resource groups). ie The "login" state could be associated with 

* the resource /foo/bar/login.html or 
* the resource group /fee/foo/fum/login.* (which includes images) or 
* a set of resources/resource groups for each "view" (xml/html/wml/pdf).

The mapping from state to resource* will not be discussed further just
here. Suffice to say that it was relatively easy given the proper

Transitions were a more difficult thing to describe. They are what has been
called an "action" - but in a generalised form. So even the humble
hyperlink (if "jumps" into another state in system) is considered an
action. Note that "actions" at this level are coarse and can actually be
sets of "actions".

The way that transitions are expressed is naturally "view" dependent. ie
ascii doesn't have the notion of a hyperlink nor does a heavyweight GUI
application. These were a lot harder to map to a particular view.
(Especially considering some views can not represent the transition).

The best way to model this is to adopt the technique used by many
web-application style setups (ie velocity+turbine). Associate with each
state context-data. The context data is a map of name to value. For
instance it may map the "next" command to
"". It is up to each specific view
renderer to render the action as appropriately as possible.

Of course this method is plagued with it's own set of problems. If you have
ever worked with context based systems you realize that it is easy to mess
up contexts. If Component1 places data in under name "foo" which is
required by Component2 then you change Component1 but forget to update
Component2 - most apps will run - but produce invalid results. So in my
system I thought it would be wise to make each component swear to a
contract. ie. Each component must declare which data it can put in context
and which is required.

So Component Foo may produce context-data "fee" and "phi" while it requires
"fo" and "fum". The assembler then can arbitrarily map data between
different components (ie the component may place "fum" into context which
next component requires as "foo").

This is not the only pain in dealing with context-style approach. You also
have to deal with "typing". Ie can the particualr ViewRenderer handle
context data of type "link". HtmlViewRenderer can do just that but ascii
renderer can't. This thus has to be detected and the CMAP developer warned.

So what the CMAP is essentially about is defining states and transitions
between states that match the user experience. However in the CMAP there
are certain states that are accessible to the "outside" world. The Login
screen for instance is accessible but the command screens are not. In HTTP
this would be dealt with by mapping all "hidden" states to one URI but
differentiating by cookie/post/session data. All "exported" states would
have a different URI (or a set of URIs - one for each view).

In a lot of ways the current C2 siitemap is a degenerate form of processed
CMAP. Every state is exported, states are already processed into resources
etc. However the current C2 sitemap does not provide graceful support for
alternative technologies (ala Velocity/jsp/whatever-you-fancy) as
resources. C2 also forces you to map a resource to URI which implies it is
impossible to have a hidden state.

As each component in the CMAP declares which data it needs and which it
uses it is also trivial to do caching. You just look at inputs to each
component - see what their lifecycle is (ie
static/per-session/per-request/other) and then cache component if required.
You can also calculate average runtimes of each component to figure into
equation determining whether or not to cache.

There are some advantages to an approach like this - it means you can
choose what ever technology you please (ie jsp/struts or velocity/turbine
or cocoon/xsp etc). It means you get cheap/free caching. It also means you
get lower development costs while your UI people do tests/revise etc ;)

The downside is that it may be more difficult to use the "content" outside
CMAP because it relies on context information (ie extentions and variables
in XSLT, variables in velocity etc). It may also be waaaaaaaaaaaay overkill
for a simple document collection. However assuming it was implemented right
and Transitions were decomposed into several actions I think it would win
out easily on medium+ sites.

However saying all this - one of the main reasons this never got
implemented is that it is a HUGE amount of work. It would also require
meta-information about each content item (or looser contracts and content
grouping) which can be a drain at the begining of developing content.

Anyways theres my 2c ;)



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

View raw message