cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: [RT] Flowmaps
Date Tue, 18 Jun 2002 19:43:52 GMT
Some rather random thoughts:

A flow (workflow) can be represented as a DAG. An edge
in the DAG represents a page sent to the user, and a
certain set of data recieved as a result of a user
action. The same page sent to a user may be part of
many different edges, which are differentiated by the
result data. Whether it is useful to have several
outgoing pages associated with an edge is a matter
of opinion, I'd prefer several, parallel edges instead.

There are several possibilities to describe a DAG
representing a flow:
- Focus on the nodes. Declare the incoming and outgoing
  edges. This is quite similar to the current ssitemap
  approach, with a complex matcher matching potentially
  both on the location part of the URL as well as the
  parameters, then invoking the business logic, and
  finally generating one of many possible output
  pages.
- Focus on the edges. Describe an edge as a pair
  consisting of an outgoing page and a match on the
  result data, rather similar to the description
  above. Declare nodes separately and reference them
  from the edge. There is still the problem of describing
  the selection of the outgoing page, which somehow must
  be attached to the node description.

The conceptual difficulty in either of the approaches
above is that the same outgoing page can be associated
(does "start") several different edges, the real edge
to traverse is only determined after the response from
the user (i.e. the next *request* to the server) has
been matched. Using the same page in the description
for several edges can be seen as introducing redundancy,
therefore declaring them separately and reference them
in the edge description can be useful.

Then there is the problem of a hidden state, for example
whether the user has successfully logged in. While this
is commonly seen as error situation, this formally adds
a huge amount of edges to the flow graph, usually making
it completely incomprehensible.

Each of the approaches has its merits. There are a lot
of degrees of freedom in designing a web application.
It could be useful to fix some choices and see what
can happen to the others.

1. Only a very limited set of push buttons on each page,
as an extreme case, use only an "ok" (think of the
browser's "back" button as "cancel") everything else is
"data" and is handled by lower level application code, not
by the flow description. In this case, there is a one-to-one
mapping from pages to edges, apart from hidden state
concerns. Because the description of the edges is rather
trivial, it makes sense to focus on the nodes.

2. Each nodes generates exactly one page. In this case,
the page selection after the business logic of a node is
performed becomes trivial, and the page can be dropped
from the edge description.

3. Combine 1+2. This gives a linear flow, the simplest
possible flow available. Not very useful in itself but
serves as a base for more complicated patterns.

4. A flow where two edges flow out of each edge (except
the last), one ending in an "cancel node", one ending in
the next node. This is a common pattern in GUI "wizards",
especially if you allow for expanding nodes into sub-flows.
This means two buttons per page "ok" (next node) and
"cancel" (the whole task so far).
Node and edge description is still simple, provided the
"cancel node"  for the whole flow is specifically marked.

5. Additionally to 4, edges which bent back to the node
where they come from. Something like "reenter or complete
data". These edges can be implicitely added, because there
is only one edge and one page coming from another node
to the actual node, so resending it is trivial.

6. Sub-flows. If a sub-flow exits for whatever reason,
the or one of the edges flowing out of the parent node
of the sub-flow is activated.

Designing and describing a general flow is far from trivial.
Well, workflow applications/toolkits usually come with a
graphical designer.

UML provides two diagrams for expressing some sort
of flows: state diagrams and activity diagrams. The
latter are meanwhile quite often used for designing
workflows, or flows of objects, or whatever similar
concept one likes to discuss.

There is an open source UML editor, ArgoUML, they
support activity diagrams, it is Java, and the model
is saved as XMI, which is XML of course. Perhaps
this could be taken advantage of?

J.Pietschmann


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


Mime
View raw message