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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
