[RT] Another Attack on Flowmap Problem

[ma...@tiger.com.pl]

Intro
~~~~~
Last August I was in Altay Mountains in Syberia with intention to climb
Mt Belucha. At the begining I had rainy weather an I had a lot of time to think.
Among others I researched some aspects of Coocon suitability for web applications. 
Concepts was promising but as after a few days, sun eventualy come out and I left them 
rough and unpolished for later investigation.

As the discussion has already started I send this ideas unpolished to enrich 
the "ideas pulp" which Cocoon community use to form solutions from.

General constraints
~~~~~~~~~~~~~~~~~~~
 1. Simple mapping between url and actions is not enough.
 2. Some form of controller is necessary. To control interactions
    between views available to the user(view means url) and 
    objects and actions in the backend.
 3. Approach should allow division of work into modules. Eg. It should be possible
    to define login actions separately from eg. data entry actions
 4. It should not sacrifice important sitemap concepts: 
    uri space control, pipelines

Sample application:
~~~~~~~~~~~~~~~~~~~
General Form Processing Problem(GFPP).

Attack method
~~~~~~~~~~~
Let's take transition net concept, which is general enough 
to describe web application and try to enrich its semantics so 
resulting model meets above constraints.

Here is transition net of GFPP:

                    +--------------+
              +---->| Introduction |<-------------------------+
              |     +--------------+                          |
              |             |                                 |
    [cancel{resetform}]  [start]                              |
              |             |                                 |
              |             V                                 |
              |     +--------------+                          |
              +-----| Form         |<-----------------+       |
                    +--------------+                  |       |
                            |                         |   [restart{resetform}]
                       [validation{validate}]         |       |
                            |                         |       |
                            | (not valid)             |       |
                            +-------------------------+       |
                            |                                 |
                            | (valid)                         |
                            |                                 | 
                            V                                 |
                    +--------------+                          |
                    | Done         |--------------------------+
                    +--------------+


There are tree states:
<<introduction>>, <form>, <done>

One state is initial:
<<introduction>>

States are connected with transitions:
[start], [cancel], [validation], [restart]

Some transitions are associated with transitions:
[validation{validate}], [cancel{resetform}], [restart{resetform}]

One action returns result:
{validate}
Valid results are: valid, not valid
Transition associated with action returning result forks state flow.
Action description may be further enriched with parameters declaration.

Compact notation:
<<introduction>>
    [start]-><form>

<form>
    [cancel{resetform}]    -> <introduction>
    [validation{validate}] -> (not valid)<form>, (valid)<done>

<done>
    [restart{resetform}] -> <introduction>    

I hope above is pretty obvious.

Nothing has been said so far about data presentation means. I assume that data is presented 
via set of pipelines: |intro|, |form|, |help|, |done|.

                                    --o--

Ok. So far we have a description of flow of application and a bunch of pipelines.
To make full web application description out of it, it is necessary to map user 
view of the system (uris) to it. Idea is to apply sitemap concept for each state 
separately. To each state are assigned mappings from uris to pipelines and transitions which
describe what data and what actions are available in given state. Transitions and pipelines 
are mapped separately. Requests are processed in following steps:
 1. Identify current state, if current state is not defined, then set state to default.
 2. Match transitions mapping of current state. Fire transition. If does not contain action 
    than simple change current state to new one. If it contains action execute action and change 
    state. If action returns result than change state according to result.
 3. If current state has been changed during this request then execute default pipeline. Otherwise
    (no transition has been matched) match and execute pipeline mappings of current state.

Default pipeline of state concept is necessary because when transition changes state 
it should be clear which pipeline to chose. It can't be decided on uri basis because 
uri is meaningful for previous state not the current one.

It is possible to change uri without state change. It is useful for states like <form> where
two pipelines are mapped:    /form -> |form| and /help -> |help|.

Notation /form -> |form| means that uri /form is mapped to pipeline |form|.

Here is enriched description:

<<introduction>>
    pipelines:
        default: |intro|                           
    transitions:
        /start   -> [start]-><form>                
<form>
    pipelines:
        default: |form|
        /form     -> |form| 
        /help     -> |help| 
    transitions:
        /cancel   -> [cancel{resetform}] -> <introduction>
        /validate -> [validation{validate}] -> (not valid)<form>, (valid)<done>

<done>
    pipelines:
        default: |done|
    transitions:
        /restart  -> [restart{resetform}] -> <introduction>    

Division of work into modules
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Problem: given two transition nets eg: authentication net and form processing net, 
compose them somehow to get compound net that describes compound application.

I propose hierarchical net composition. It consists in making states of one net substates 
of one of states of another net.

Example: Authentication net has state logged:
...
<logged>
    pipelines:
        default: |menu|
    transitions:
        /logout   -> [logout] -> <notlogged>
    subnets:
        /form  -> !form processing net!

Than when in state logged user can enter state <<introduction>> in form processing net via uri /form.

It is just an idea. Semantics of net composition should be further investigated.



Maciek Kaminski
maciejka@tiger.com.pl

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