You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniela Gehle <d....@levigo.de> on 2001/10/09 16:47:53 UTC
[RT] Flowmaps revisited
Dear Cocooners,
I've been following your discussions concerning the Flowmap topic with
high interest, as our company is working on a web application showing
exactly the same problems that could be solved by some kind of Flowmap
or Transition Map (as I prefer to call it to avoid confusion with the
ongoing Flowmap proposals). We've been reading and discussing your
proposed approaches carefully and found valuable inspiration in it.
(Although some parts of your proposals are still covered with mist, for
example the usage of filters in Berin's proposal. Maybe someone else can
enlighten us. :-)
Resulting from these considerations we envision a slightly different and
"lighter", but not less powerful way to implement flow control in Cocoon
2, which I would like to present you herein.
This approach is "lighter" in the sense that it can easily be integrated
into the current Cocoon 2 framework using the actors concept. Once the
Cocoon Sitemap implementation will change from compiled to interpreted,
this approach can easily be adapted and integrated into the new Sitemap
concept. But for now all we want is a generalized implementation without
any changes affecting the Cocoon framework itself.
Of course we would like to contribute the implementation of this
Transition Map approach to the Cocoon project, so please let me know
what you think about it, if we misunderstood some of your points or if
we are missing any important details. The proposal itself is not
entirely fixed yet (and of course not yet coded as well :-), so you
still have the opportunity to influence the design we propose, to make
it perfectly fit into the Cocoon framework.
Ok, fastened your seat belts? - So let's start with the explanation:
---------------------------------------------------
Reminder: Pages, navigation and flow.
---------------------------------------------------
One of our web applications requires the user to step through a number
of pages in a controlled sequence (or "flow"). Each of these pages is
accompanied by background "actions" performed by Java classes. These
actions concern data generation as well as data processing. From each of
these pages just a very small, context-dependant subset of other pages
is accessible, and only these transitions should be displayed to the
user. What makes these transitions even more complicated, is that some
of them require not just the target URL but additional data that will be
processed by the underlying program logic.
This is very much in contrast to most of the common web applications
where you have some kind of general navigation menu accessible from
each of the pages and provide the same navigational links for all of the
pages.
Therefore we can distinguish two different types of navigation:
- navigation as a way to consistently structure and group resources
(mostly in a hierarchical manner) and make them accessible for the user
in a fashionable way (we could call this type of navigation "static
navigation"), and
- navigation that refers to states in a flow and grants access to a
subset of pages that are part of a flow. We call this type of navigation
"flow navigation" from now on.
Static navigation is a pretty simple issue, so we will concentrate on
flow navigation in this article. As a special aspect of the flow control
presented here, the approach provides a mechanism to generate these
"flow navigation" elements automatically from the state description in
the Transition Map. As far as I know, this is a topic that has never
been addressed on the Cocoon list before.
I don't want to confuse you - so I will touch this mechanism only
marginally within this presentation, but in fact it is an important
requirement that had fundamental influence on the presented design. If
you are interested, let me know, and I will feed you with additional
details.
---------------------------------------------------
What issues do we cover?
---------------------------------------------------
Now that we know the rough picture it is time to look a little bit
closer at what requirements have to be met exactly. This flow handling
approach covers not only flow control itself but some additional aspects
as well:
(1) Controlling the flow (i.e. state transitions) of the application.
(2) Separation of data processing ("control" aspect of the MVC pattern)
and data generation ("view" aspect of the MVC pattern).
(3) User authentication and authorization.
(4) Jumping to any visible state in the middle of the flow in one hop.
(5) Automatic generation of "flow navigation" elements for each page.
(6) Handle form submits.
(7) Support generation of forms.
We will see how all this works together later.
--------------------------------------------------------
Sample application
--------------------------------------------------------
The problem description is borrowed from the concept of finite state
machines and relies on a formal description of states and transitions.
Please note that this is the main difference to the previous
propositions on this list - we do not just concentrate on the states,
but on transitions as well. Each transition requires a particular set of
parameters tied to the transition. These parameters are used to generate
flow navigation elements and forms.
Let me explain this with an example. Assume a flow representing an
archive searching application requiring user authentication. For
example, think of a newspaper article archive containing articles to
several topics where autorized journalists are allowed to drop queries.
The page sequence that is crossed performing a query might look like
this:
login -> topic-selection -> search-form -> result-list ->
article-display
The main processing direction is forward, but a backward navigation to
any of the previous pages has to be supported as well. If you are
currently looking at a newspaper article (article-display page), you
might want to jump to the page where you can change the selection of the
topic (topic-selection page). Or you might want to change your password
from any of the pages - this means that access to a "change-password"
page must be possible from every page.
This shows us that the flow is NOT just a simple sequence of pages
processed in a row, but of a much more complex structure (which is not
really easy to draw in ASCII graphics and therefore be omitted here :-).
Moreover, we have been cheating a little bit so far. The flow consists
not only of pages - representing visible states of the system
(accessible via an URL) - but also of hidden states where system
operations are performed (like data verification or query processing).
These hidden states can lead to visible states or to other hidden
states.
Therefore, the login sequence of the above mentioned page flow should
better be written like this:
login --(AUTH)--> [check-login] --(AUTH-OK)--> topic-selection ->..
login <--(AUTH-NOT-OK)--|
Please note that in this notation the transitions themselves have unique
names like (AUTH) or (AUTH-OK), and the hidden state [check-login] is
marked with square brackets to illustrate the difference to visible
states. As its name proposes, the [check-login] state verifies and
processes the data entered in the login form on the login page.
Another important point is that the transitions are transporting data
from one state to another. The (AUTH) transition, for example, carries
fields like username="paul" and password="foo". These fields will be
evaluated by the subsequent state.
Now we can put together a description of all states and all transitions
in a Transition Map:
--------------------------------------------------------
The Transition Map
--------------------------------------------------------
<flow start="login" name="search-archive">
<transitions>
<transition name="AUTH" target-state="check-login">
<parameters>
<parameter name="username" xpath="/environment/user"/>
<parameter name="password" xpath="/environment/pass"/>
</parameters>
</transition>
<transition name="AUTH-OK" target-state="topic-selection"/>
<transition name="AUTH-NOT-OK" target-state="login"/>
<transition name="SELECTTOPIC" target-state="find-topic">
<parameters>
<parameter name="topic" xpath="/topics/topic"/>
</parameters>
</transition>
<transition name="LOGOUT" target-state="perform-logout"/>
...
</transitions>
<states>
<state name="login" resource="*/login">
<if event="AUTH" transition="AUTH"/>
<if event="CHANGEPASS" transition="CHANGEPASS"/>
</state>
<state name="check-login">
<act type="LoginAction"/>
<if event="OK" transition="AUTH-OK"/>
<if event="ERROR" transition="AUTH-NOT-OK"/>
</state>
<state name="topic-selection" resource="*/topic-selection">
<if event="LOGOUT" transition="LOGOUT"/>
<if event="SELECT" transition="SELECTTOPIC"/>
</state>
<state name="perform-logout">
<act type="LoginAction"/>
<if event="OK" transition="LOGOUT-OK"/>
<if event="ERROR" transition="LOGOUT-NOT-OK"/>
</state>
...
</states>
</flow>
A Transition Map can contain several flow definitions, each of them
carrying a unique name and being responsible for a different functional
unit (<flow start="..." name="...">).
The first part of each flow definition consists of the definition of all
transitions (<transitions> ... </transitions>). Each transition is
described by a unique name, a target state and the parameters that are
required for this transition. These parameters are NOT necessary for the
flow control itself, but they are for form handling and automatic
generation of flow navigation elements. They result either from filling
form fields or represent environmental data provided by the data
generation classes. The latter can be evaluated automatically by using a
specialized "FlowNavigation" transformer, but I don't want to mix up
things here, so I'm concealing the details of this transformer for now.
To describe the flow as a whole we do not just need the transitions but
also information about the states and by which transitions they are
connected. The state descriptions (<state>...</state>) distinguish
between visible and hidden states. Visible states can be reached by
requesting a specific URL - hidden states cannot. Visible states carry
the URL resource they are mapped to in the resource parameter of the
<state> element; hidden states carry information about the handler that
is executed when entering the state. These handlers can be implemented
as actors. It might be possible for a visible state to contain a handler
as well, but this is not recommended, because then the clean separation
of visible and hidden states would be broken.
The decision which of the possible transitions to follow at a specific
point is done by evaluating the transition event parameters. These
parameters are either URL parameters (in the case of a visible state) or
result parameters of an action (in the case of a hidden state). Event
parameters are written in Capitals in order easily distinguish them from
ordinary parameters.
--------------------------------------------------------
Sitemap configuration: the FlowHandlerAction
--------------------------------------------------------
In order to control the flow and the state transitions there is a
FlowHandlerAction hooked up in the Sitemap. More precisely, the
FlowHandlerAction will be performed for each URL that is representing a
(visible) state in the flow. The FlowHandlerAction has to be fed with
the name of the flow for each pattern match within a flow.
The Sitemap contains something like
<map:match pattern="in-the-flow/*">
<map:act type="FlowHandler">
<map:parameter name="search-archive"/>
</map:act>
<map:act type="AuthenticationAction">
<map:redirect-to uri="in-the-flow/login"/>
</map:act>
<map:generate type="saxlet" src="templates/{1}.xml"/>
<map:transform src="styles/{1}.xsl"/>
<map:serialize/>
</map:match>
The Transition Map file itself will be specified within the definition
section of the FlowHandlerAction:
<map:actions>
<map:action name="FlowHandler" src="org.bar.foo.FlowHandlerAction">
<map-file>transitionmap.xmap</map-file>
</map:action>
</map:actions>
--------------------------------------------------------
Are all the promised features there?
--------------------------------------------------------
(1) Controlling the flow (i.e. state transitions) of the application? -
Yes.
(2) Separation of data processing ("control" aspect of the MVC pattern)
and data generation ("view" aspect of the MVC pattern)?
Yes. Control is performed by the handlers of the hidden states, data
generation is performed by the specific Generator (ServerPagesGenerator,
SAXLet Generator,...) for each page representing a visible state.
(3) User authentication and authorization?
Yes. Except for the login process itself which is performed by the
LoginAction Handler of the "check-login" state, user authentication and
authorization are located in the AuthenticationAction used in the
Sitemap. Please note that this is one of the main differences to Berin's
proposal, were an authorization mechanism was part of the flowmap
itself. We decided to put the authentication and authorization aspects
apart, because not all applications rely on the same consistent
authentication/authorization mechanism. Therefore, in order to be open
to any authentication/authorization requirements, it seemed to make more
sense to place them in actors called from within the Sitemap or the
Transition Map. Of course, a combination of both approaches is perfectly
possible.
(4) Jumping to any visible state in the middle of the flow in one hop?
Yes. This is possible, provided that the necessary ordinary and event
parameters for the march along the transitions leading to the desired
target state are passed along with the HTTP request. As long as the
required parameters for the transitions between the states are contained
in the URL, the state machine will jump from state to state without
bothering the user with displaying pages belonging to intermediate
states.
For example: If you want to jump to the state "search-form" without
crossing the "login" page, you can enter the URL:
http://foo.bar/in-the-flow/login?username=Paul&password=foo&AUTH=true&topic=squirrels&SELECT=true.
Starting from the "login" state the subsequent states "check-login",
"topic-selection" and "find-topic" are automatically crossed, leading to
the target state "search-form" (and displaying the "search-form" page to
the user).
(5) Automatic generation of "flow navigation" elements for each page?
Yes. This task will be performed by a specialized FlowNavigation
transformer using the xpath attributes of the transition descriptions in
the Transition Map, matching them against XML elements of the generated
data and inserting generic "flow navigation" controls in the XML data
that is being processed.
(6) Handle form submits?
Yes. Default target of a form submit is always the current page (=state)
itself. The FlowHandlerAction checks if there's an event parameter
triggering a transition leading to another state (according to the state
and transition description in the Transition Map) or if there is no
matching event parameter and the page itself has to be generated.
(7) Support generation of forms?
Yes, this is possible in combination with flows, but not implemented
yet. Using a form descriptor similar to the <parameters> element of the
transition description in the Transition Map, forms can be generated in
a unified way, with the default form submit target being the current
page.
-------------------------------------------------------------
How does this proposal fit into the future plans for Cocoon?
-------------------------------------------------------------
That's a point pretty hard to answer for me, because I cannot sneak in
the heads of the Cocoon front row developers. All I could do is point
out the aspects we've been considering. Now it's your turn, please throw
your stones. ;-)
Thanks,
Dani
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Frank Taffelt <fr...@interface-business.de>.
Hi,
great!! I'm also very interested in this topic.
3 weeks ago, i also started to implement a statemachine as a controller in a
MVC scenario embedded in cocoon2 as the publishing layer.
it would be fine, to share all the ideas in this topic to make cocoon2 ready
for applications.
it's really funny, to see that others has the same things in mind !!
i will left the pro's and contra's because you explained them very well.
ok, here is my solution:
the flow is defined in a separate place:
<states init="forminit">
<state name="forminit" view="forminit_view">
<transition to="formaction">
<event>add</event>
<action name="add" fail="error"/>
</transition>
<transition to="formaction">
<event>remove</event>
<action name="remove" fail="error"/>
</transition>
<transition to="formsubmit">
<event>submit</event>
<action name="submit" fail="error"/>
</transition>
</state>
<state name="formaction" view="formaction_view">
<transition to="formaction">
<event>add</event>
<action name="add" fail="error"/>
</transition>
<transition to="formaction">
<event>remove</event>
<action name="remove" fail="error"/>
</transition>
<transition to="formsubmit">
<event>submit</event>
<action name="submit" fail="error"/>
</transition>
</state>
<state name="navigation" view="nav_menu">
<transition to="forminit">
<event>nav</event>
<condition type="request" name="choice" value="edit"/>
<action name="initdata" fail="error"/>
</transition>
</state>
<state name="formsubmit" view="formsubmit_view">
</state>
<state name="formcancel" view="formcancel_view"/>
<state name="error" view="formerror_view"/>
</states>
the entry in the sitemap:
<map:match pattern="fxforms-state/*.fxf">
<map:act type="statemachine" src="&fxforms;/fxforms.xml">
<map:parameter name="prefix" value="&fxforms;/actions/"/>
<map:parameter name="eventgenerator"
value="de.ifbus.cocoon2.fxforms.FXFormsEventGenerator"/>
<!-- the view parameter seems to be a bug !! -->
<map:redirect-to resource="{../view}" target="{../1}"/>
</map:act>
</map:match>
the "eventgenerator"-parameter is responsible for generating application
depending events and delegates them to the statemachine for evaluating.
after evaluating the next state and applicationlogic (during the
transition), let cocoon publish the data
(redirecting to a sitemap defined resource) :
<map:resource name="forminit_view">
<map:aggregate element="fxforms">
<map:part src="cocoon:/fxforms/model/{target}.xml"/>
<map:part src="cocoon:/fxforms/data/{target}.xml"/>
</map:aggregate>
<map:transform src="&fxforms;/stylesheets/fxforms_html.xsl"/>
<map:transform src="&fxforms;/stylesheets/validation_layer.xsl"/>
<map:serialize type="html"/>
</map:resource>
<map:resource name="formsubmit_view">
<map:generate type="serverpages" src="&fxforms;/view/showdata.xsp"/>
<map:serialize type="xml"/>
</map:resource>
showdata is a small xsp-page generating xml from the Application:
<!-- example -->
<data>
<xsp:logic>
DOMStreamer ds = new DOMStreamer (new
EmbeddedXMLPipe(this.xmlConsumer));
<!-- the data is stored in the session, i think there are better ways
for doing that -->
Document doc =
(Document )request.getSession(true).getAttribute("FXFORMS_DATA_XPATH");
ds.stream (doc);
</xsp:logic>
</data>
A possible problem can occur if a page is opening an extra window (with
javascript) in the application flow. The application is in 2 parallel states
at the same time. A possible solution can be a FSM with substates ??
I hope to give this discussion some new sights and would like to get some
feedback in this topic.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Agree with that : with the recent discussions on the tree-traversal
> implementation of the sitemap, there comes a need to cleanly separate
> the current implementation of the sitemap from the Cocoon class itself.
> For now, they're a little bit intermixed and Sitemap isn't handled like
> other components in cocoon.xconf. Once they're separated, the door will
> be opened to alternative implementations, the first one being the
> interpreted sitemap.
Exactly!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Jason Foster a écrit :
>
> This is fun! :)
>
> > Meanwhile, and just to add some FFT, I think that some previous study on
> > finite state machines might help the discussion. I found really
> > valuable, while oriented specifically to concurrency issue, the
> > Magee&Kramer book (Concurrency. state models & Java programs) which uses
> > heavily the FSP (Finite State Process) formalism together with the LTS
> > (Labeled Transition System) modeling.
>
> I was poking around Slashdot and noticed a thread on Lisp, which in turn
> mentioned Haskell. While I've never used either language extensively, it
> looks to me like a functional approach to expressing a web page or
> application may have merit.
>
> Based on my very limited knowledge, instead of defining all states and
> transitions explicitly, you specify individual dependencies and let an
> inference engine take care of things.
>
> This sounds neat as it allows SOC within the webapp definition. Two groups
> can work on different aspects of the webapp independently, and then the
> system can integrate them once a single dependency is defined. Of course
> you could probably do this in a state machine as well...
>
> The more I think about it, the more I think that there are two distinct
> aspects to Cocoon. The first is the underlying plumbing (Generators,
> Transformers, Serializers), based exclusively on the decision to use a
> cached SAX stream. The second part is the mechanism that links the plumbing
> together (Sitemap, Flowmap).
>
> I'm about ready to propose that Cocoon should *not* impose any particular
> way of connecting things, in the same way that we don't impose any
> particular way of generating SAX events. It would be really cool to allow
> people to use State Machines, Inference Engines, JavaScript, Python, the
> Sitemap, or any other thing they can dream up to connect the basic
> components. Sort of like "Avalon for XML"?
Agree with that : with the recent discussions on the tree-traversal
implementation of the sitemap, there comes a need to cleanly separate
the current implementation of the sitemap from the Cocoon class itself.
For now, they're a little bit intermixed and Sitemap isn't handled like
other components in cocoon.xconf. Once they're separated, the door will
be opened to alternative implementations, the first one being the
interpreted sitemap.
> But that's another story ;) (1)
Or maybe not ?
> Jason Foster
>
> (1) I always liked Hammy Hamster, for all you Canadians out there ;)
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Jason Foster wrote:
> The more I think about it, the more I think that there are two distinct
> aspects to Cocoon. The first is the underlying plumbing (Generators,
> Transformers, Serializers), based exclusively on the decision to use a
> cached SAX stream. The second part is the mechanism that links the plumbing
> together (Sitemap, Flowmap).
Yes. This is correct. Call it internal SoC, if you wish.
> I'm about ready to propose that Cocoon should *not* impose any particular
> way of connecting things, in the same way that we don't impose any
> particular way of generating SAX events.
In that respect, Berin already proposed to make the sitemap engine
pluggable. This, in short, means to have a pluggable "pipeline plumber".
I think this is still a good idea. But...
> It would be really cool to allow
> people to use State Machines, Inference Engines, JavaScript, Python, the
> Sitemap, or any other thing they can dream up to connect the basic
> components. Sort of like "Avalon for XML"?
... flexibility syndrome: Cocoon and Avalon are already complex enough
for people to start with, if we don't even give them the ability to
assemble their pipelines in a simple way, nobody is ever going to do
anything with it since the entry curve is way too steep.
But, again, I agree that a pluggable plumber is definately a good thing
from an architectural view just as we provide you the ability to write
your own generators, but then we give you XSP to help you on 80% of your
needs.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Jason Foster <ja...@uwaterloo.ca>.
This is fun! :)
> Meanwhile, and just to add some FFT, I think that some previous study on
> finite state machines might help the discussion. I found really
> valuable, while oriented specifically to concurrency issue, the
> Magee&Kramer book (Concurrency. state models & Java programs) which uses
> heavily the FSP (Finite State Process) formalism together with the LTS
> (Labeled Transition System) modeling.
I was poking around Slashdot and noticed a thread on Lisp, which in turn
mentioned Haskell. While I've never used either language extensively, it
looks to me like a functional approach to expressing a web page or
application may have merit.
Based on my very limited knowledge, instead of defining all states and
transitions explicitly, you specify individual dependencies and let an
inference engine take care of things.
This sounds neat as it allows SOC within the webapp definition. Two groups
can work on different aspects of the webapp independently, and then the
system can integrate them once a single dependency is defined. Of course
you could probably do this in a state machine as well...
The more I think about it, the more I think that there are two distinct
aspects to Cocoon. The first is the underlying plumbing (Generators,
Transformers, Serializers), based exclusively on the decision to use a
cached SAX stream. The second part is the mechanism that links the plumbing
together (Sitemap, Flowmap).
I'm about ready to propose that Cocoon should *not* impose any particular
way of connecting things, in the same way that we don't impose any
particular way of generating SAX events. It would be really cool to allow
people to use State Machines, Inference Engines, JavaScript, Python, the
Sitemap, or any other thing they can dream up to connect the basic
components. Sort of like "Avalon for XML"?
But that's another story ;) (1)
Jason Foster
(1) I always liked Hammy Hamster, for all you Canadians out there ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Gianugo Rabellino <gi...@rabellino.it>.
Ciao,
> > > This will finally give a "global" view of what a web application
does
> > > and how it does it in all places both in the publishing of each
state
> >
> > Which, if sticking to my notation, would be "... each _visible_
state...".
this is really great stuff, and I'm eager to put up a comprehensive
reply with my ideas about it.
Meanwhile, and just to add some FFT, I think that some previous study on
finite state machines might help the discussion. I found really
valuable, while oriented specifically to concurrency issue, the
Magee&Kramer book (Concurrency. state models & Java programs) which uses
heavily the FSP (Finite State Process) formalism together with the LTS
(Labeled Transition System) modeling. FSP is a quite powerful ASCII
notation that can be easily parsed in order to produce a state model:
it defines quite cleary states, transitions and actions that can take
place in an arbitrary flow. It might seem a bit ankward in the
beginning, but if you get used it becomes quite natural and expressful.
You can read more about FSP at
http://www.doc.ic.ac.uk/~jnm/LTSdocumention/FSP-notation.html, where
resources for LTS can be found too at the site home page
(http://www-dse.doc.ic.ac.uk/concurrency/). Tthere is also a Java
tool - the LTS Analyzer ot LTSA - which is pretty cool in animating the
process flow designed in FSP.
I still need to study it a bit more but, for what I have seen until now,
it seems to me a powerful and well established notation in the CS world:
how about exploring the opportunity to use this meta language (and maybe
some of the available tools) to further carry on this (and possibly
others) thread? We might discover that FSP expresses quite well our
needs and maybe come up with the Flowmap being expressed as an "XMLized"
FSP language.
Just my 0.02 euro. :)
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> > So, the atom of state transition for the web using visible and invisible
> > states can be pictured as something like this:
>
> Aha, this time it's sure, Stefano is really back ;)
Thanks :)
> I love RTs ! This is a part of what makes this project so great : no
> fear to think out loud in the open.
Exactly. Many people do open source. Here, we do "open development"
which, of course, in order to work requires the source to be available
in an truly open way.
Big difference and the results show it.
> I'd like to add some thoughts on "flow navigation" without waiting for
> Daniela's description.
Great, the more ideas to stymulate us, the better the results will be.
> From what I've understood, this concerns the
> automatic analysis of which transitions are possible from a given state.
Yes and it's a good thing indeed: the more the framework does, the less
you have to do :)
> There come two requirements for a useful system : transition
> authorization and transition classification.
>
> Transition authorization :
> ------------------------
> In all desktop-based applications, tool bars and menus expose the
> actions available to the user, but some of them are deactivated. Such
> deactivated actions represent possible transitions (described in a
> flowmap), but which aren't currently available because the application
> context doesn't allow them. Many things in the context can lead a
> transition to be unavailable. Some examples : user isn't in the right
> group, current selection doesn't allow a given action, subsystem
> temporarily unavailable, etc.
Ok, good parallel.
> Such restrictions could be represented explicitly in the flowmap, but
> would lead to an over-complexified graph where each possible combination
> is handled separately and wouldn't allow the display of transitions that
> are disabled because of the context (either as greyed buttons or
> non-linked text).
Right.
> The solution here can be the use of boolean selectors that filter events
> in the "states" element :
> <state name="display-data">
> <select type="someDataSelected">
> <if event="DELETE" transition="DELETE"/>
> </select>
> ...
> </state>
>
> This also allows to solve some of the secutity issues related to
> stateless HTTP. Event selectors are tested twice : once for displaying
> the page associated to the state, and once when handling the request.
> Thus someone cannot manually build the URL that fires "DELETE" if the
> system doesn't allow it.
Hmmm, very good point.
> Transition classification :
> -------------------------
> Once we have a mean to automatically build a list of available
> transitions from the current state, we can define generic presentation
> templates to layout them on the page. But a page has several areas where
> transitions can be displayed, so we need to be able to classify
> transitions to be able to dispatch them in the adequate area. This is
> where subflowmap can be very useful : it seems to me that we can
> consider that each transition display area contains either the list of
> available transitions in a single functional area, or lists the entry
> points to separate functional areas.
Hmmm, not sure I follow you here. Can you elaborate more?
> So we could consider that functional areas of the application should be
> organized in hierarchical flowmaps. A navigation menu is then the list
> of available transitions of the top-level flowmap, and buttons like
> "validate" and "next" are the list of the available transitions of the
> lowest-level flowmap. Just like top-level menus, sub-menus can be the
> list of transitions of intermediate-level flowmaps.
>
> <snip/>
>
> > > > > --------------------------------------------------------
> > > > > The Transition Map
> > > > > --------------------------------------------------------
> > > > > <flow start="login" name="search-archive">
> > > > > <transitions>
> > > > > <transition name="AUTH" target-state="check-login">
> > > > > <parameters>
> > > > > <parameter name="username" xpath="/environment/user"/>
> > > > > <parameter name="password" xpath="/environment/pass"/>
> > > > > </parameters>
> > > > > </transition>
> > > >
> > > > Shouldn't a transition be described by two states, the target *and* the
> > > > originating point? Maybe not, but this may generate collisions.
> > >
> > > I don't think so.
> > >
> > > A big advantage if you don't specify the originating point is that you can
> > > "reuse" transitions. For example: you can use the "LOGOUT" transition from
> > > any desired page. If the description of the transition contained the
> > > originating state, you would need to specify n LOGOUT transitions, one for
> > > each originating page, all with a different name, but the same parameter set
> > > and all with the same target. And I don't suppose that that's what you want.
> > > :)
> >
> > Good point. :)
> >
> > > Our first design kept the <transitions> enclosed in the <state> element, but
> > > after some reflection we found that it is much more elegant to separate the
> > > <transitions> from the <states> in order to reuse them and to avoid
> > > redundancy.
> >
> > Sounds very declerative to me: good choice.
>
> Yes, but this enforces the need to have subflowmaps, otherwhise naming
> transitions with unique names throughout the whole system will be a
> headache !
Absolutely, there needs to be sort of context-based namespacing in order
to avoid name collisions, but that is a semantic detail and should be
dealt with when discussing the semantics in detail, we are still at a
more general level.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi a écrit :
>
> Daniela Gehle wrote:
>
> > Correct. We've made exactly this experience when developing a small
> > application a few weeks ago, and we all were (or at least, most of us were
> > :-) very unhappy with the first implementation which mixed flow instructions
> > (i.e. target resources) into program logic (i.e. actions).
> >
> > That was the reason for us to go a step back and think about a clearer
> > separation of concerns in a more elegant concept. And that's where the
> > Flowmap jumps onto the scene.
>
> I think that more or less every cocoon user will hit that wall, yes. So,
> we must have plans on how to remove that wall before too much people run
> into it and get hurt.
Seems that many cocoon users already hit it, hence the large interest
for this subject :)
I'm also really interested in flowmaps, and want to thank Daniela for
her great proposal.
<snip/>
> So, the atom of state transition for the web using visible and invisible
> states can be pictured as something like this:
Aha, this time it's sure, Stefano is really back ;)
I love RTs ! This is a part of what makes this project so great : no
fear to think out loud in the open.
<snip/>
> > > > I don't want to confuse you - so I will touch this mechanism only
> > > > marginally within this presentation, but in fact it is an important
> > > > requirement that had fundamental influence on the presented design. If
> > > > you are interested, let me know, and I will feed you with additional
> > > > details.
> > >
> > > Please do.
> >
> > Sure. :) I'm going to post a more detailed description asap. (Hopefully
> > today or tomorrow, I'm kind of torn between several projects at the moment,
> > so please excuse if my response time isn't perfectly short...)
>
> No problem.
I'd like to add some thoughts on "flow navigation" without waiting for
Daniela's description. From what I've understood, this concerns the
automatic analysis of which transitions are possible from a given state.
There come two requirements for a useful system : transition
authorization and transition classification.
Transition authorization :
------------------------
In all desktop-based applications, tool bars and menus expose the
actions available to the user, but some of them are deactivated. Such
deactivated actions represent possible transitions (described in a
flowmap), but which aren't currently available because the application
context doesn't allow them. Many things in the context can lead a
transition to be unavailable. Some examples : user isn't in the right
group, current selection doesn't allow a given action, subsystem
temporarily unavailable, etc.
Such restrictions could be represented explicitly in the flowmap, but
would lead to an over-complexified graph where each possible combination
is handled separately and wouldn't allow the display of transitions that
are disabled because of the context (either as greyed buttons or
non-linked text).
The solution here can be the use of boolean selectors that filter events
in the "states" element :
<state name="display-data">
<select type="someDataSelected">
<if event="DELETE" transition="DELETE"/>
</select>
...
</state>
This also allows to solve some of the secutity issues related to
stateless HTTP. Event selectors are tested twice : once for displaying
the page associated to the state, and once when handling the request.
Thus someone cannot manually build the URL that fires "DELETE" if the
system doesn't allow it.
Transition classification :
-------------------------
Once we have a mean to automatically build a list of available
transitions from the current state, we can define generic presentation
templates to layout them on the page. But a page has several areas where
transitions can be displayed, so we need to be able to classify
transitions to be able to dispatch them in the adequate area. This is
where subflowmap can be very useful : it seems to me that we can
consider that each transition display area contains either the list of
available transitions in a single functional area, or lists the entry
points to separate functional areas.
So we could consider that functional areas of the application should be
organized in hierarchical flowmaps. A navigation menu is then the list
of available transitions of the top-level flowmap, and buttons like
"validate" and "next" are the list of the available transitions of the
lowest-level flowmap. Just like top-level menus, sub-menus can be the
list of transitions of intermediate-level flowmaps.
<snip/>
> > > > --------------------------------------------------------
> > > > The Transition Map
> > > > --------------------------------------------------------
> > > > <flow start="login" name="search-archive">
> > > > <transitions>
> > > > <transition name="AUTH" target-state="check-login">
> > > > <parameters>
> > > > <parameter name="username" xpath="/environment/user"/>
> > > > <parameter name="password" xpath="/environment/pass"/>
> > > > </parameters>
> > > > </transition>
> > >
> > > Shouldn't a transition be described by two states, the target *and* the
> > > originating point? Maybe not, but this may generate collisions.
> >
> > I don't think so.
> >
> > A big advantage if you don't specify the originating point is that you can
> > "reuse" transitions. For example: you can use the "LOGOUT" transition from
> > any desired page. If the description of the transition contained the
> > originating state, you would need to specify n LOGOUT transitions, one for
> > each originating page, all with a different name, but the same parameter set
> > and all with the same target. And I don't suppose that that's what you want.
> > :)
>
> Good point. :)
>
> > Our first design kept the <transitions> enclosed in the <state> element, but
> > after some reflection we found that it is much more elegant to separate the
> > <transitions> from the <states> in order to reuse them and to avoid
> > redundancy.
>
> Sounds very declerative to me: good choice.
Yes, but this enforces the need to have subflowmaps, otherwhise naming
transitions with unique names throughout the whole system will be a
headache !
> I'm going to try to come up with an example statemap and then we can
> work on that. If anybody else wants to do it, he/she will be very
> welcome to do so. The more ideas thrown in, the better.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
Daniela Gehle wrote:
> Correct. We've made exactly this experience when developing a small
> application a few weeks ago, and we all were (or at least, most of us were
> :-) very unhappy with the first implementation which mixed flow instructions
> (i.e. target resources) into program logic (i.e. actions).
>
> That was the reason for us to go a step back and think about a clearer
> separation of concerns in a more elegant concept. And that's where the
> Flowmap jumps onto the scene.
I think that more or less every cocoon user will hit that wall, yes. So,
we must have plans on how to remove that wall before too much people run
into it and get hurt.
> > This information, the very heart of the web application, the blue-prints
> > to build it and manage it, should be found elsewhere.
> >
> > This will finally give a "global" view of what a web application does
> > and how it does it in all places both in the publishing of each state
>
> Which, if sticking to my notation, would be "... each _visible_ state...".
Uh, picky girl, I love it :)
> > and in the operation performed during transition between one state and
> > another.
>
> And again: "... between one _visible_ state and another." And the operations
> would be performed in the hidden states. But that's nitpicking. :)
No, you are right: the dual concept of visible/invisible states is the
true architectural advancement.
In fact, I thought that even "hyperlinking" can be seen as a particular
transition between states where the invisible state performs the null
action and has only two connections.
So, a link between resource A and B can be pictured as
[A] ---> (link) ---> [B]
where [] are visible states and () invisible ones (I like this notation,
is very simple but very expressive). The invisible state doesn't perform
any "routing" for hyperlinks, but might do for, say, login forms
[login] ----> (validate) -{valid}-> [next]
^ |
| {invalid}
| |
+---------------+
where, the notation adds the curly braces that represents the route
name.
So, the atom of state transition for the web using visible and invisible
states can be pictured as something like this:
+---------------{loop}--------------+
| ^
v |
[A] ----> (action1) ---------------->+
| | |
| +------{1}-----> [R11] |
| | |
| +------{2}-----> [R12] |
| ... |
| +------{n}-----> [R1n] |
| |
+------> (action2) ---------------->+
| | |
| +------{1}-----> [R21] |
| | |
| +------{2}-----> [R22] |
| ... |
| +------{n}-----> [R2n] |
... |
+------> (actionm) ---------------->+
|
+------{1}-----> [Rm2]
|
+------{2}-----> [Rm2]
...
+------{n}-----> [Rmn]
and I believe that *all* web sites can be modelled by attaching one
transition atom to the next.
The resulting graph is, in theory, very complex, but it's pretty rare
that visible state connects to more than one "complex" invisible state.
So, the flowmap must be semantically capable of expressing the above
"transition atom", as well as allowing different flowmaps to be
componentized.
How? well, allowing states to be "hookable". Say, for example, that you
have a login webapp that you want to share between different webapps
that require authentication.
The state diagram
[login] -> (validate) -> [valid]
should allow sub-flowmaps to say that one of their states should
"inherit" the functionality of the state "valid", so
flowmap A states: [login] -> (validate) -> [valid]
flowmap B states: [search] -> (check form) -> [results]
global flowmap states: [B:search] := [A:valid]
then the two can be used glued together.
This would be pretty damn cool, wouldn't it?
> I understand your point perfectly. I personally don't like unelegant
> solutions, too. But there is ONE problem: we need that stuff pretty soon
> now. If you think that it's likely that the sitemap redesign and
> reimplementation will be in place within a few weeks, this is a solution we
> could perfectly live with. But it would be really inconvenient to lose more
> time on that. And exactly that was the reason why we came up with this
> "fit-in-both-concepts" design approach.
Ok, that wasn't clear in your first mail but it is now. I understand.
> Do you have already anything particular in mind concerning the sitemap
> restructuring and the flowmap stuff?
No, nothing in particular, I'm still coming from a very global
abstraction view, I'm not ready to dive into semantics until the
complete picture is presented and I'd like to throw more ideas around
and see where they land and what they spark in other people's minds.
> Do you suspect any specific collisions and problems?
I have the feeling (nothing rational but I've learned to listen to those
things) that the difficult point is establishing separation of concerns
between sitemaps and flowmaps.
In fact, with the global vision above, the sitemap is just a piece of
the more general "statemap" of the finite state machine and it's going
to require major contract establishment to be able to separate state
transitions (flowmap?) from state descriptions (sitemap?)
Thus the feeling that the sitemap is, in fact, a very specific
"statemap" but with an implicit flowmap where each transition is, in
fact, a simple hyperlink.
With this vision, it is easy to understand why I see your proposal as
dangerous: you are adding flow information to the existing sitemap and
this might cut the concerns in the wrong place, creating crosscutting
concerns between the two files and forcing regular updates to happen in
both files.
Thinking at a way more general "statemap" which contains both the
sitemap semantics AND the proposed flowmap capacity of describing state
transitions and the parameters associated with the routing choice will
result, later on, in a better separation on concerns on all the files
involved in describing this information.
I don't know, at this point, if one cascaded schema is required or if
one defines pipelines in different files then references the pipelines
by name, or whatever other mechanism to make it easier to edit those
files by hand and reuse them as much as possible without mixing concerns
and forcing multiple updates.
But, at this point, it doesn't (yet) matter: we must come up with a
global and complete architectural vision, then cut it in different
orthogonal concerns and at the end come up with the semantics that
describes it.
Of course, I'm talking about the perfect choice here, if you people want
to add it first as a proof of concept, I won't be the one to stop you.
> > Berin and I already expressed the intention to have the possibility to
> > navigate to abstract states that do not represent a real resource. Such
> > as the "next" target after you completed a form, or something like that.
> >
> > This is probably part of what you call "flow navigation".... hmmm, have
> > to think more about this...
>
> Ahh, I see.... Seems I didn't express myself clear enough on that point.
>
> Flow navigation does not mean how to navigate between states of a flow in
> general.
>
> Flow navigation means placing URLs/links on HTML/WML/... pages, with the
> specialty
>
> - that these links lead to other states of the flow,
> - that these links can carry additional parameters and
> - these links are generated automatically from the Transition Map
> description
> - specifically for the current page.
Hmmm, I think we need to think more generally than this if we want to
come up with something that can truly stand the tons of features people
will ask for. :)
> > > I don't want to confuse you - so I will touch this mechanism only
> > > marginally within this presentation, but in fact it is an important
> > > requirement that had fundamental influence on the presented design. If
> > > you are interested, let me know, and I will feed you with additional
> > > details.
> >
> > Please do.
>
> Sure. :) I'm going to post a more detailed description asap. (Hopefully
> today or tomorrow, I'm kind of torn between several projects at the moment,
> so please excuse if my response time isn't perfectly short...)
No problem.
[...]
> Fine. :) In fact, after coming up with the clear separation of visible and
> hidden states and naming transitions, everyone of us was somehow struck as
> well, because this model seemed the first to be "clean" and all the ugly
> tricks we had to use in our former models vanished in an instant.
Exactly! :) This is why I search for global visions and good
architectures: when you find it, you know it by heart and I have the
feeling this is one major step forward in the right direction.
> > > Now we can put together a description of all states and all transitions
> > > in a Transition Map:
> > >
> > > --------------------------------------------------------
> > > The Transition Map
> > > --------------------------------------------------------
> > > <flow start="login" name="search-archive">
> > > <transitions>
> > > <transition name="AUTH" target-state="check-login">
> > > <parameters>
> > > <parameter name="username" xpath="/environment/user"/>
> > > <parameter name="password" xpath="/environment/pass"/>
> > > </parameters>
> > > </transition>
> >
> > Shouldn't a transition be described by two states, the target *and* the
> > originating point? Maybe not, but this may generate collisions.
>
> I don't think so.
>
> A big advantage if you don't specify the originating point is that you can
> "reuse" transitions. For example: you can use the "LOGOUT" transition from
> any desired page. If the description of the transition contained the
> originating state, you would need to specify n LOGOUT transitions, one for
> each originating page, all with a different name, but the same parameter set
> and all with the same target. And I don't suppose that that's what you want.
> :)
Good point. :)
> Our first design kept the <transitions> enclosed in the <state> element, but
> after some reflection we found that it is much more elegant to separate the
> <transitions> from the <states> in order to reuse them and to avoid
> redundancy.
Sounds very declerative to me: good choice.
> Maybe the transition should NOT even contain the target state to make them
> even more reusable. Transition would just be a named set of parameters then.
> But I'm not sure... This might lead to unwanted collisions.
Ok.
> > > [...]
> > >
> > > It might be possible for a visible state to contain a handler
> > > as well, but this is not recommended, because then the clean separation
> > > of visible and hidden states would be broken.
> >
> > Agreed. I like this separation very much. In fact, I never liked the
> > action proposal in the sitemap since the granularity of reusability of
> > actors is visibly different from that of sitemap components.
> >
> > But in flowmaps, actors really shine.
>
> So you're thinking of removing the actors from the sitemap and permit them
> just in the flowmap itself?
I'd love to see that. Actors are turning the sitemap into a programming
language and it's not what I'd like to happen.
But we need more thoughts on this.
> > > The decision which of the possible transitions to follow at a specific
> > > point is done by evaluating the transition event parameters. These
> > > parameters are either URL parameters (in the case of a visible state) or
> > > result parameters of an action (in the case of a hidden state). Event
> > > parameters are written in Capitals in order easily distinguish them from
> > > ordinary parameters.
> >
> > Or might be otherwise namespaced, but I think this is just an
> > implementation detail.
>
> Right. The Capitals were just invented to ease reading.
>
> > > --------------------------------------------------------
> > > Sitemap configuration: the FlowHandlerAction
> > > --------------------------------------------------------
> > > In order to control the flow and the state transitions there is a
> > > FlowHandlerAction hooked up in the Sitemap.
> >
> > This is what I don't like that much. I think flowmaps are important
> > enough to require a more specific hook-up semantics and the action
> > framework might allow this, but maybe there are more elegant solutions.
> > (I'm picky, I know)
>
> Well, then let's hear what you'd prefer. :)
As I said, I'd love to see one global description (even one single file
would work for now) of the site statemap, including visible state
description (resources), invisible state description (actions) and state
transitions (flows).
I know it's going to be a huge file, but then we'll know how to separate
it in pieces as we did with the subsitemap concept *after* the sitemap
was created.
> > > More precisely, the
> > > FlowHandlerAction will be performed for each URL that is representing a
> > > (visible) state in the flow. The FlowHandlerAction has to be fed with
> > > the name of the flow for each pattern match within a flow.
> > >
> > > The Sitemap contains something like
> > >
> > > <map:match pattern="in-the-flow/*">
> > > <map:act type="FlowHandler">
> > > <map:parameter name="search-archive"/>
> > > </map:act>
> > > <map:act type="AuthenticationAction">
> > > <map:redirect-to uri="in-the-flow/login"/>
> > > </map:act>
> > > <map:generate type="saxlet" src="templates/{1}.xml"/>
> > > <map:transform src="styles/{1}.xsl"/>
> > > <map:serialize/>
> > > </map:match>
> > >
> > > The Transition Map file itself will be specified within the definition
> > > section of the FlowHandlerAction:
> > >
> > > <map:actions>
> > > <map:action name="FlowHandler" src="org.bar.foo.FlowHandlerAction">
> > > <map-file>transitionmap.xmap</map-file>
> > > </map:action>
> > > </map:actions>
> >
> > This is exactly the inelegance I was talking about: sounds like an hack
> > to me.
>
> It IS a hack, of course. ;)
>
> > Let's work out a specific semantic addition for flowmaps.
>
> Agreed, this would be much better. Any ideas?
I'm going to try to come up with an example statemap and then we can
work on that. If anybody else wants to do it, he/she will be very
welcome to do so. The more ideas thrown in, the better.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[RT] Another Attack on Flowmap Problem
Posted by 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
Re: [RT] Flowmaps revisited
Posted by Daniela Gehle <d....@levigo.de>.
Hi Stefano,
> Dear Daniela, welcome aboard the magic wonders of Cocoon RT series :)
yeah, these RTs are something special indeed. And thanks a lot for the warm
welcome. :)
> I believe that almost everybody working on web applications (even the
> most simple ones) have the same problems of publishing resources
> (states) and controlling the flow between them (transitions).
>
> In fact, as you write below, a webapp can (and should!) be seen as a
> finite state machine. The problem with currently available technologies
> (even most advanced webapp frameworks developped by the ASF) is that the
> information that "programs" the FSM (finite state machine) is built-in
> into the programming layer. While I agree there is room for people to
> like this approach, I don't and I'd like the FSM instructions *not* to
> be part of the programming logic itself, but part of configurations that
> drive the framework.
Correct. We've made exactly this experience when developing a small
application a few weeks ago, and we all were (or at least, most of us were
:-) very unhappy with the first implementation which mixed flow instructions
(i.e. target resources) into program logic (i.e. actions).
That was the reason for us to go a step back and think about a clearer
separation of concerns in a more elegant concept. And that's where the
Flowmap jumps onto the scene.
> This follows the same pattern that saw Cocoon1 being hard to manage
> because pipeline instructions were written inside documents and not
> outside of them.
>
> So, just like PI that dynamically assembled pipelines in reactors were
> cool on paper but turned out to be impractical compared to a centralized
> approach like the sitemap, I believe the exact same can be said for FSM
> instructions.
>
> So, I'm fully convinced that in order to enforce separation of concerns,
> programming logic, documents and other component resources should *NOT*
> contain information on states nor their transitions, not how to compose
> them.
Absolutely.
> This information, the very heart of the web application, the blue-prints
> to build it and manage it, should be found elsewhere.
>
> This will finally give a "global" view of what a web application does
> and how it does it in all places both in the publishing of each state
Which, if sticking to my notation, would be "... each _visible_ state...".
> and in the operation performed during transition between one state and
> another.
And again: "... between one _visible_ state and another." And the operations
would be performed in the hidden states. But that's nitpicking. :)
> > We've been reading and discussing your
> > proposed approaches carefully and found valuable inspiration in it.
>
> Same here :)
perfect!
> [...]
>
> > This approach is "lighter" in the sense that it can easily be integrated
> > into the current Cocoon 2 framework using the actors concept.
>
> Personally, I believe that global elagance has higher priority than
> instant integration with existing solutions. Not that I don't care about
> back portability, rather the opposite in face: I believe that a well
> thought-out and designed technology is much more likely to remain
> untouched once all the details are considered globally, rather than
> incrementally.
>
> Adding flowmap capacities to the existing sitemap might be possible, but
> might sacrifice elegance and ease of use and I wouldn't want that at
> this point.
I understand your point perfectly. I personally don't like unelegant
solutions, too. But there is ONE problem: we need that stuff pretty soon
now. If you think that it's likely that the sitemap redesign and
reimplementation will be in place within a few weeks, this is a solution we
could perfectly live with. But it would be really inconvenient to lose more
time on that. And exactly that was the reason why we came up with this
"fit-in-both-concepts" design approach.
Do you have already anything particular in mind concerning the sitemap
restructuring and the flowmap stuff?
Do you suspect any specific collisions and problems?
> [...]
>
> I'd love to welcome you guys aboard and I think we'll all be happy to
> invite you to join us in our effort toward the same goals.
Thanks, we'll do our very best. :-)
> > [...]
> >
> > - navigation that refers to states in a flow and grants access to a
> > subset of pages that are part of a flow. We call this type of navigation
> > "flow navigation" from now on.
> >
> > Static navigation is a pretty simple issue, so we will concentrate on
> > flow navigation in this article. As a special aspect of the flow control
> > presented here, the approach provides a mechanism to generate these
> > "flow navigation" elements automatically from the state description in
> > the Transition Map. As far as I know, this is a topic that has never
> > been addressed on the Cocoon list before.
>
> Not really, but sure not in such a great detail.
>
> Berin and I already expressed the intention to have the possibility to
> navigate to abstract states that do not represent a real resource. Such
> as the "next" target after you completed a form, or something like that.
>
> This is probably part of what you call "flow navigation".... hmmm, have
> to think more about this...
Ahh, I see.... Seems I didn't express myself clear enough on that point.
Flow navigation does not mean how to navigate between states of a flow in
general.
Flow navigation means placing URLs/links on HTML/WML/... pages, with the
specialty
- that these links lead to other states of the flow,
- that these links can carry additional parameters and
- these links are generated automatically from the Transition Map
description
- specifically for the current page.
> > I don't want to confuse you - so I will touch this mechanism only
> > marginally within this presentation, but in fact it is an important
> > requirement that had fundamental influence on the presented design. If
> > you are interested, let me know, and I will feed you with additional
> > details.
>
> Please do.
Sure. :) I'm going to post a more detailed description asap. (Hopefully
today or tomorrow, I'm kind of torn between several projects at the moment,
so please excuse if my response time isn't perfectly short...)
> > [...]
> >
> > The main processing direction is forward, but a backward navigation to
> > any of the previous pages has to be supported as well. If you are
> > currently looking at a newspaper article (article-display page), you
> > might want to jump to the page where you can change the selection of the
> > topic (topic-selection page). Or you might want to change your password
> > from any of the pages - this means that access to a "change-password"
> > page must be possible from every page.
>
> Yes and good usability will place even more navigation complexity even
> for those static navigation resources. (to be honest, I tend to believe
> a good site will almost never have static navigation for usability
> reasons, but I might be wrong)
In my opinion, this depends to a great extent on the purpose of the site. If
it's just an information publishing site, you can be perfectly happy with
static navigation. At least that's what everyone is used to and what
everyone expects from a static navigation on a web site.
But as soon as even the smallest controlled flow comes into action, you're
lost and you will need something else to support the navigation within the
flow.
> > This shows us that the flow is NOT just a simple sequence of pages
> > processed in a row, but of a much more complex structure (which is not
> > really easy to draw in ASCII graphics and therefore be omitted here :-).
>
> Yes, I've already drawn these pictures on my whiteboard before and I
> know what you mean. In fact, one of my feature-dreams is to be able to
> draw a nice SVG poster of such complex FSM graph directly transforming
> sitemap/flowmap information. But that is future stuff :)
Sounds futuristic indeed. :)
> > Moreover, we have been cheating a little bit so far. The flow consists
> > not only of pages - representing visible states of the system
> > (accessible via an URL) - but also of hidden states where system
> > operations are performed (like data verification or query processing).
> > These hidden states can lead to visible states or to other hidden
> > states.
>
> Uh, this is what was left on my picture. Hmmmm, very interesting....
> very interesting...
>
> > Therefore, the login sequence of the above mentioned page flow should
> > better be written like this:
> >
> > login --(AUTH)--> [check-login] --(AUTH-OK)--> topic-selection ->..
> > login <--(AUTH-NOT-OK)--|
> >
> > Please note that in this notation the transitions themselves have unique
> > names like (AUTH) or (AUTH-OK), and the hidden state [check-login] is
> > marked with square brackets to illustrate the difference to visible
> > states. As its name proposes, the [check-login] state verifies and
> > processes the data entered in the login form on the login page.
>
> I love this!
Fine. :) In fact, after coming up with the clear separation of visible and
hidden states and naming transitions, everyone of us was somehow struck as
well, because this model seemed the first to be "clean" and all the ugly
tricks we had to use in our former models vanished in an instant.
> > Now we can put together a description of all states and all transitions
> > in a Transition Map:
> >
> > --------------------------------------------------------
> > The Transition Map
> > --------------------------------------------------------
> > <flow start="login" name="search-archive">
> > <transitions>
> > <transition name="AUTH" target-state="check-login">
> > <parameters>
> > <parameter name="username" xpath="/environment/user"/>
> > <parameter name="password" xpath="/environment/pass"/>
> > </parameters>
> > </transition>
>
> Shouldn't a transition be described by two states, the target *and* the
> originating point? Maybe not, but this may generate collisions.
I don't think so.
A big advantage if you don't specify the originating point is that you can
"reuse" transitions. For example: you can use the "LOGOUT" transition from
any desired page. If the description of the transition contained the
originating state, you would need to specify n LOGOUT transitions, one for
each originating page, all with a different name, but the same parameter set
and all with the same target. And I don't suppose that that's what you want.
:)
Our first design kept the <transitions> enclosed in the <state> element, but
after some reflection we found that it is much more elegant to separate the
<transitions> from the <states> in order to reuse them and to avoid
redundancy.
Maybe the transition should NOT even contain the target state to make them
even more reusable. Transition would just be a named set of parameters then.
But I'm not sure... This might lead to unwanted collisions.
> > [...]
> >
> > It might be possible for a visible state to contain a handler
> > as well, but this is not recommended, because then the clean separation
> > of visible and hidden states would be broken.
>
> Agreed. I like this separation very much. In fact, I never liked the
> action proposal in the sitemap since the granularity of reusability of
> actors is visibly different from that of sitemap components.
>
> But in flowmaps, actors really shine.
So you're thinking of removing the actors from the sitemap and permit them
just in the flowmap itself?
> > The decision which of the possible transitions to follow at a specific
> > point is done by evaluating the transition event parameters. These
> > parameters are either URL parameters (in the case of a visible state) or
> > result parameters of an action (in the case of a hidden state). Event
> > parameters are written in Capitals in order easily distinguish them from
> > ordinary parameters.
>
> Or might be otherwise namespaced, but I think this is just an
> implementation detail.
Right. The Capitals were just invented to ease reading.
> > --------------------------------------------------------
> > Sitemap configuration: the FlowHandlerAction
> > --------------------------------------------------------
> > In order to control the flow and the state transitions there is a
> > FlowHandlerAction hooked up in the Sitemap.
>
> This is what I don't like that much. I think flowmaps are important
> enough to require a more specific hook-up semantics and the action
> framework might allow this, but maybe there are more elegant solutions.
> (I'm picky, I know)
Well, then let's hear what you'd prefer. :)
> > More precisely, the
> > FlowHandlerAction will be performed for each URL that is representing a
> > (visible) state in the flow. The FlowHandlerAction has to be fed with
> > the name of the flow for each pattern match within a flow.
> >
> > The Sitemap contains something like
> >
> > <map:match pattern="in-the-flow/*">
> > <map:act type="FlowHandler">
> > <map:parameter name="search-archive"/>
> > </map:act>
> > <map:act type="AuthenticationAction">
> > <map:redirect-to uri="in-the-flow/login"/>
> > </map:act>
> > <map:generate type="saxlet" src="templates/{1}.xml"/>
> > <map:transform src="styles/{1}.xsl"/>
> > <map:serialize/>
> > </map:match>
> >
> > The Transition Map file itself will be specified within the definition
> > section of the FlowHandlerAction:
> >
> > <map:actions>
> > <map:action name="FlowHandler" src="org.bar.foo.FlowHandlerAction">
> > <map-file>transitionmap.xmap</map-file>
> > </map:action>
> > </map:actions>
>
> This is exactly the inelegance I was talking about: sounds like an hack
> to me.
It IS a hack, of course. ;)
> Let's work out a specific semantic addition for flowmaps.
Agreed, this would be much better. Any ideas?
> > --------------------------------------------------------
> > Are all the promised features there?
> > --------------------------------------------------------
> > (1) Controlling the flow (i.e. state transitions) of the application? -
> > Yes.
> >
> > (2) Separation of data processing ("control" aspect of the MVC pattern)
> > and data generation ("view" aspect of the MVC pattern)?
> >
> > Yes. Control is performed by the handlers of the hidden states, data
> > generation is performed by the specific Generator (ServerPagesGenerator,
> > SAXLet Generator,...) for each page representing a visible state.
> >
> > (3) User authentication and authorization?
> >
> > Yes. Except for the login process itself which is performed by the
> > LoginAction Handler of the "check-login" state, user authentication and
> > authorization are located in the AuthenticationAction used in the
> > Sitemap. Please note that this is one of the main differences to Berin's
> > proposal, were an authorization mechanism was part of the flowmap
> > itself. We decided to put the authentication and authorization aspects
> > apart, because not all applications rely on the same consistent
> > authentication/authorization mechanism. Therefore, in order to be open
> > to any authentication/authorization requirements, it seemed to make more
> > sense to place them in actors called from within the Sitemap or the
> > Transition Map. Of course, a combination of both approaches is perfectly
> > possible.
>
> I think we must elaborate more on this, but I want more feedback before
> stating something on this topic since I'm not really an expert on this.
>
> > (4) Jumping to any visible state in the middle of the flow in one hop?
> >
> > Yes. This is possible, provided that the necessary ordinary and event
> > parameters for the march along the transitions leading to the desired
> > target state are passed along with the HTTP request. As long as the
> > required parameters for the transitions between the states are contained
> > in the URL, the state machine will jump from state to state without
> > bothering the user with displaying pages belonging to intermediate
> > states.
> > For example: If you want to jump to the state "search-form" without
> > crossing the "login" page, you can enter the URL:
> > http://foo.bar/in-the-flow/login?username=Paul&password=foo&AUTH=true&topic=squirrels&SELECT=true.
> > Starting from the "login" state the subsequent states "check-login",
> > "topic-selection" and "find-topic" are automatically crossed, leading to
> > the target state "search-form" (and displaying the "search-form" page to
> > the user).
>
> Or even have a sitemap matcher retokenize your encoded URI to come up
> with that information. A great thing would be to automatically provide a
> form with all the fields already complete but those missing or invalid.
> So, for example the password doesn't need to be explicitly written in
> the URI but everything else.
Futuristic, but cool ideas again. :)
> > (5) Automatic generation of "flow navigation" elements for each page?
> >
> > Yes. This task will be performed by a specialized FlowNavigation
> > transformer using the xpath attributes of the transition descriptions in
> > the Transition Map, matching them against XML elements of the generated
> > data and inserting generic "flow navigation" controls in the XML data
> > that is being processed.
>
> Hmmm, this might lead to concern overlap so we must be careful, but in
> general, I see some great value on this.
Concern overlap in what respect?
> > (6) Handle form submits?
> >
> > Yes. Default target of a form submit is always the current page (=state)
> > itself.
>
> YES! This is a conclusion that I drew as well.
Fine. :)
> > The FlowHandlerAction checks if there's an event parameter
> > triggering a transition leading to another state (according to the state
> > and transition description in the Transition Map) or if there is no
> > matching event parameter and the page itself has to be generated.
> >
> > (7) Support generation of forms?
> >
> > Yes, this is possible in combination with flows, but not implemented
> > yet. Using a form descriptor similar to the <parameters> element of the
> > transition description in the Transition Map, forms can be generated in
> > a unified way, with the default form submit target being the current
> > page.
>
> This should definately work closer with Berin's project on XForm.
Sure. It's important to design the stuff in an open and general way and to
tune it so that it works together with other components smoothly.
> Probably he'll have more things to say on this.
Probably we'll have more things to say as well. :) We're working on a form
handling and validation component as well, and we'll be ready to present the
concept on this list soon. But this might take a few more days, as the work
is still in progress and the developer who's responsible for this component
is currently on holiday...
> [...]
>
> I think you also considered a high priority to use the existing
> framework without changing things, but I repeat that I'd like to shoot
> for elegance at this point than back compatibility, expecially for such
> an important thing.
>
> So, good job, welcome aboard and let's keep beating the iron.
Yepp! It's your turn again now. :)
Ciao,
Dani
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT] Flowmaps revisited
Posted by Stefano Mazzocchi <st...@apache.org>.
First of all, let me say once again that it's a hell of a pleasure to be
part of such architectural discussions: this is real fun for me :)
Daniela Gehle wrote:
>
> Dear Cocooners,
Dear Daniela, welcome aboard the magic wonders of Cocoon RT series :)
> I've been following your discussions concerning the Flowmap topic with
> high interest, as our company is working on a web application showing
> exactly the same problems that could be solved by some kind of Flowmap
> or Transition Map (as I prefer to call it to avoid confusion with the
> ongoing Flowmap proposals).
I believe that almost everybody working on web applications (even the
most simple ones) have the same problems of publishing resources
(states) and controlling the flow between them (transitions).
In fact, as you write below, a webapp can (and should!) be seen as a
finite state machine. The problem with currently available technologies
(even most advanced webapp frameworks developped by the ASF) is that the
information that "programs" the FSM (finite state machine) is built-in
into the programming layer. While I agree there is room for people to
like this approach, I don't and I'd like the FSM instructions *not* to
be part of the programming logic itself, but part of configurations that
drive the framework.
This follows the same pattern that saw Cocoon1 being hard to manage
because pipeline instructions were written inside documents and not
outside of them.
So, just like PI that dynamically assembled pipelines in reactors were
cool on paper but turned out to be impractical compared to a centralized
approach like the sitemap, I believe the exact same can be said for FSM
instructions.
So, I'm fully convinced that in order to enforce separation of concerns,
programming logic, documents and other component resources should *NOT*
contain information on states nor their transitions, not how to compose
them.
This information, the very heart of the web application, the blue-prints
to build it and manage it, should be found elsewhere.
This will finally give a "global" view of what a web application does
and how it does it in all places both in the publishing of each state
and in the operation performed during transition between one state and
another.
> We've been reading and discussing your
> proposed approaches carefully and found valuable inspiration in it.
Same here :)
> (Although some parts of your proposals are still covered with mist, for
> example the usage of filters in Berin's proposal. Maybe someone else can
> enlighten us. :-)
RT are what they are: random thoughs spoken loudly in order to sparkle
creative discussions. So they normally have black spots where lights has
yet to show the inner details.
> Resulting from these considerations we envision a slightly different and
> "lighter", but not less powerful way to implement flow control in Cocoon
> 2, which I would like to present you herein.
>
> This approach is "lighter" in the sense that it can easily be integrated
> into the current Cocoon 2 framework using the actors concept.
Personally, I believe that global elagance has higher priority than
instant integration with existing solutions. Not that I don't care about
back portability, rather the opposite in face: I believe that a well
thought-out and designed technology is much more likely to remain
untouched once all the details are considered globally, rather than
incrementally.
Adding flowmap capacities to the existing sitemap might be possible, but
might sacrifice elegance and ease of use and I wouldn't want that at
this point.
> Once the
> Cocoon Sitemap implementation will change from compiled to interpreted,
> this approach can easily be adapted and integrated into the new Sitemap
> concept. But for now all we want is a generalized implementation without
> any changes affecting the Cocoon framework itself.
It would be great if this was possible, but again, just to let you know,
I personally don't consider this to be a very high priority: the sitemap
semantics already show some weak points and with the planned webapp
componentization, we already have lots of things to consider. The
flowmap concept is the other big thing that will have to find a good
place.
So, I'd rather discuss about the best way to do it, rather than how to
do it with existing semantics.
this said, again, if current semantics turns out to be what we wanted,
even better :)
> Of course we would like to contribute the implementation of this
> Transition Map approach to the Cocoon project, so please let me know
> what you think about it, if we misunderstood some of your points or if
> we are missing any important details. The proposal itself is not
> entirely fixed yet (and of course not yet coded as well :-), so you
> still have the opportunity to influence the design we propose, to make
> it perfectly fit into the Cocoon framework.
I'd love to welcome you guys aboard and I think we'll all be happy to
invite you to join us in our effort toward the same goals.
> Ok, fastened your seat belts? - So let's start with the explanation:
>
> ---------------------------------------------------
> Reminder: Pages, navigation and flow.
> ---------------------------------------------------
> One of our web applications requires the user to step through a number
> of pages in a controlled sequence (or "flow"). Each of these pages is
> accompanied by background "actions" performed by Java classes. These
> actions concern data generation as well as data processing. From each of
> these pages just a very small, context-dependant subset of other pages
> is accessible, and only these transitions should be displayed to the
> user. What makes these transitions even more complicated, is that some
> of them require not just the target URL but additional data that will be
> processed by the underlying program logic.
>
> This is very much in contrast to most of the common web applications
> where you have some kind of general navigation menu accessible from
> each of the pages and provide the same navigational links for all of the
> pages.
>
> Therefore we can distinguish two different types of navigation:
>
> - navigation as a way to consistently structure and group resources
> (mostly in a hierarchical manner) and make them accessible for the user
> in a fashionable way (we could call this type of navigation "static
> navigation"), and
>
> - navigation that refers to states in a flow and grants access to a
> subset of pages that are part of a flow. We call this type of navigation
> "flow navigation" from now on.
>
> Static navigation is a pretty simple issue, so we will concentrate on
> flow navigation in this article. As a special aspect of the flow control
> presented here, the approach provides a mechanism to generate these
> "flow navigation" elements automatically from the state description in
> the Transition Map. As far as I know, this is a topic that has never
> been addressed on the Cocoon list before.
Not really, but sure not in such a great detail.
Berin and I already expressed the intention to have the possibility to
navigate to abstract states that do not represent a real resource. Such
as the "next" target after you completed a form, or something like that.
This is probably part of what you call "flow navigation".... hmmm, have
to think more about this...
> I don't want to confuse you - so I will touch this mechanism only
> marginally within this presentation, but in fact it is an important
> requirement that had fundamental influence on the presented design. If
> you are interested, let me know, and I will feed you with additional
> details.
Please do.
> ---------------------------------------------------
> What issues do we cover?
> ---------------------------------------------------
> Now that we know the rough picture it is time to look a little bit
> closer at what requirements have to be met exactly. This flow handling
> approach covers not only flow control itself but some additional aspects
> as well:
>
> (1) Controlling the flow (i.e. state transitions) of the application.
> (2) Separation of data processing ("control" aspect of the MVC pattern)
> and data generation ("view" aspect of the MVC pattern).
> (3) User authentication and authorization.
> (4) Jumping to any visible state in the middle of the flow in one hop.
> (5) Automatic generation of "flow navigation" elements for each page.
> (6) Handle form submits.
> (7) Support generation of forms.
Hey, sound magical, doesn't it? :) I'd love to have something like this
in place. Really.
> We will see how all this works together later.
>
> --------------------------------------------------------
> Sample application
> --------------------------------------------------------
> The problem description is borrowed from the concept of finite state
> machines and relies on a formal description of states and transitions.
> Please note that this is the main difference to the previous
> propositions on this list - we do not just concentrate on the states,
> but on transitions as well. Each transition requires a particular set of
> parameters tied to the transition. These parameters are used to generate
> flow navigation elements and forms.
Great. I agree this is the good place to start.
> Let me explain this with an example. Assume a flow representing an
> archive searching application requiring user authentication. For
> example, think of a newspaper article archive containing articles to
> several topics where autorized journalists are allowed to drop queries.
> The page sequence that is crossed performing a query might look like
> this:
>
> login -> topic-selection -> search-form -> result-list ->
> article-display
>
> The main processing direction is forward, but a backward navigation to
> any of the previous pages has to be supported as well. If you are
> currently looking at a newspaper article (article-display page), you
> might want to jump to the page where you can change the selection of the
> topic (topic-selection page). Or you might want to change your password
> from any of the pages - this means that access to a "change-password"
> page must be possible from every page.
Yes and good usability will place even more navigation complexity even
for those static navigation resources. (to be honest, I tend to believe
a good site will almost never have static navigation for usability
reasons, but I might be wrong)
> This shows us that the flow is NOT just a simple sequence of pages
> processed in a row, but of a much more complex structure (which is not
> really easy to draw in ASCII graphics and therefore be omitted here :-).
Yes, I've already drawn these pictures on my whiteboard before and I
know what you mean. In fact, one of my feature-dreams is to be able to
draw a nice SVG poster of such complex FSM graph directly transforming
sitemap/flowmap information. But that is future stuff :)
> Moreover, we have been cheating a little bit so far. The flow consists
> not only of pages - representing visible states of the system
> (accessible via an URL) - but also of hidden states where system
> operations are performed (like data verification or query processing).
> These hidden states can lead to visible states or to other hidden
> states.
Uh, this is what was left on my picture. Hmmmm, very interesting....
very interesting...
> Therefore, the login sequence of the above mentioned page flow should
> better be written like this:
>
> login --(AUTH)--> [check-login] --(AUTH-OK)--> topic-selection ->..
> login <--(AUTH-NOT-OK)--|
>
> Please note that in this notation the transitions themselves have unique
> names like (AUTH) or (AUTH-OK), and the hidden state [check-login] is
> marked with square brackets to illustrate the difference to visible
> states. As its name proposes, the [check-login] state verifies and
> processes the data entered in the login form on the login page.
I love this! I've been drawing this using a different scheme:
---(get)---+-> login -+-----(get)---> topic-selection
^ |
| |
+--(post)--+
but admittedly, your solution is much less HTTP-centric and much more
visually appealing.
> Another important point is that the transitions are transporting data
> from one state to another. The (AUTH) transition, for example, carries
> fields like username="paul" and password="foo". These fields will be
> evaluated by the subsequent state.
Yes.
> Now we can put together a description of all states and all transitions
> in a Transition Map:
>
> --------------------------------------------------------
> The Transition Map
> --------------------------------------------------------
> <flow start="login" name="search-archive">
> <transitions>
> <transition name="AUTH" target-state="check-login">
> <parameters>
> <parameter name="username" xpath="/environment/user"/>
> <parameter name="password" xpath="/environment/pass"/>
> </parameters>
> </transition>
Shouldn't a transition be described by two states, the target *and* the
originating point? Maybe not, but this may generate collisions.
> <transition name="AUTH-OK" target-state="topic-selection"/>
> <transition name="AUTH-NOT-OK" target-state="login"/>
> <transition name="SELECTTOPIC" target-state="find-topic">
> <parameters>
> <parameter name="topic" xpath="/topics/topic"/>
> </parameters>
> </transition>
> <transition name="LOGOUT" target-state="perform-logout"/>
> ...
> </transitions>
> <states>
> <state name="login" resource="*/login">
> <if event="AUTH" transition="AUTH"/>
> <if event="CHANGEPASS" transition="CHANGEPASS"/>
> </state>
> <state name="check-login">
> <act type="LoginAction"/>
> <if event="OK" transition="AUTH-OK"/>
> <if event="ERROR" transition="AUTH-NOT-OK"/>
> </state>
> <state name="topic-selection" resource="*/topic-selection">
> <if event="LOGOUT" transition="LOGOUT"/>
> <if event="SELECT" transition="SELECTTOPIC"/>
> </state>
> <state name="perform-logout">
> <act type="LoginAction"/>
> <if event="OK" transition="LOGOUT-OK"/>
> <if event="ERROR" transition="LOGOUT-NOT-OK"/>
> </state>
> ...
> </states>
> </flow>
I like the concept very much. Really. I have to think more about what we
need, but I think this is a very useful place to start.
> A Transition Map can contain several flow definitions, each of them
> carrying a unique name and being responsible for a different functional
> unit (<flow start="..." name="...">).
>
> The first part of each flow definition consists of the definition of all
> transitions (<transitions> ... </transitions>). Each transition is
> described by a unique name, a target state and the parameters that are
> required for this transition. These parameters are NOT necessary for the
> flow control itself, but they are for form handling and automatic
> generation of flow navigation elements. They result either from filling
> form fields or represent environmental data provided by the data
> generation classes. The latter can be evaluated automatically by using a
> specialized "FlowNavigation" transformer, but I don't want to mix up
> things here, so I'm concealing the details of this transformer for now.
>
> To describe the flow as a whole we do not just need the transitions but
> also information about the states and by which transitions they are
> connected.
Here is the tricky part.
> The state descriptions (<state>...</state>) distinguish
> between visible and hidden states. Visible states can be reached by
> requesting a specific URL - hidden states cannot. Visible states carry
> the URL resource they are mapped to in the resource parameter of the
> <state> element; hidden states carry information about the handler that
> is executed when entering the state.
Ok.
> These handlers can be implemented as actors.
Right.
> It might be possible for a visible state to contain a handler
> as well, but this is not recommended, because then the clean separation
> of visible and hidden states would be broken.
Agreed. I like this separation very much. In fact, I never liked the
action proposal in the sitemap since the granularity of reusability of
actors is visibly different from that of sitemap components.
But in flowmaps, actors really shine.
> The decision which of the possible transitions to follow at a specific
> point is done by evaluating the transition event parameters. These
> parameters are either URL parameters (in the case of a visible state) or
> result parameters of an action (in the case of a hidden state). Event
> parameters are written in Capitals in order easily distinguish them from
> ordinary parameters.
Or might be otherwise namespaced, but I think this is just an
implementation detail.
> --------------------------------------------------------
> Sitemap configuration: the FlowHandlerAction
> --------------------------------------------------------
> In order to control the flow and the state transitions there is a
> FlowHandlerAction hooked up in the Sitemap.
This is what I don't like that much. I think flowmaps are important
enough to require a more specific hook-up semantics and the action
framework might allow this, but maybe there are more elegant solutions.
(I'm picky, I know)
> More precisely, the
> FlowHandlerAction will be performed for each URL that is representing a
> (visible) state in the flow. The FlowHandlerAction has to be fed with
> the name of the flow for each pattern match within a flow.
>
> The Sitemap contains something like
>
> <map:match pattern="in-the-flow/*">
> <map:act type="FlowHandler">
> <map:parameter name="search-archive"/>
> </map:act>
> <map:act type="AuthenticationAction">
> <map:redirect-to uri="in-the-flow/login"/>
> </map:act>
> <map:generate type="saxlet" src="templates/{1}.xml"/>
> <map:transform src="styles/{1}.xsl"/>
> <map:serialize/>
> </map:match>
>
> The Transition Map file itself will be specified within the definition
> section of the FlowHandlerAction:
>
> <map:actions>
> <map:action name="FlowHandler" src="org.bar.foo.FlowHandlerAction">
> <map-file>transitionmap.xmap</map-file>
> </map:action>
> </map:actions>
This is exactly the inelegance I was talking about: sounds like an hack
to me.
Let's work out a specific semantic addition for flowmaps.
> --------------------------------------------------------
> Are all the promised features there?
> --------------------------------------------------------
> (1) Controlling the flow (i.e. state transitions) of the application? -
> Yes.
>
> (2) Separation of data processing ("control" aspect of the MVC pattern)
> and data generation ("view" aspect of the MVC pattern)?
>
> Yes. Control is performed by the handlers of the hidden states, data
> generation is performed by the specific Generator (ServerPagesGenerator,
> SAXLet Generator,...) for each page representing a visible state.
>
> (3) User authentication and authorization?
>
> Yes. Except for the login process itself which is performed by the
> LoginAction Handler of the "check-login" state, user authentication and
> authorization are located in the AuthenticationAction used in the
> Sitemap. Please note that this is one of the main differences to Berin's
> proposal, were an authorization mechanism was part of the flowmap
> itself. We decided to put the authentication and authorization aspects
> apart, because not all applications rely on the same consistent
> authentication/authorization mechanism. Therefore, in order to be open
> to any authentication/authorization requirements, it seemed to make more
> sense to place them in actors called from within the Sitemap or the
> Transition Map. Of course, a combination of both approaches is perfectly
> possible.
I think we must elaborate more on this, but I want more feedback before
stating something on this topic since I'm not really an expert on this.
> (4) Jumping to any visible state in the middle of the flow in one hop?
>
> Yes. This is possible, provided that the necessary ordinary and event
> parameters for the march along the transitions leading to the desired
> target state are passed along with the HTTP request. As long as the
> required parameters for the transitions between the states are contained
> in the URL, the state machine will jump from state to state without
> bothering the user with displaying pages belonging to intermediate
> states.
> For example: If you want to jump to the state "search-form" without
> crossing the "login" page, you can enter the URL:
> http://foo.bar/in-the-flow/login?username=Paul&password=foo&AUTH=true&topic=squirrels&SELECT=true.
> Starting from the "login" state the subsequent states "check-login",
> "topic-selection" and "find-topic" are automatically crossed, leading to
> the target state "search-form" (and displaying the "search-form" page to
> the user).
Or even have a sitemap matcher retokenize your encoded URI to come up
with that information. A great thing would be to automatically provide a
form with all the fields already complete but those missing or invalid.
So, for example the password doesn't need to be explicitly written in
the URI but everything else.
> (5) Automatic generation of "flow navigation" elements for each page?
>
> Yes. This task will be performed by a specialized FlowNavigation
> transformer using the xpath attributes of the transition descriptions in
> the Transition Map, matching them against XML elements of the generated
> data and inserting generic "flow navigation" controls in the XML data
> that is being processed.
Hmmm, this might lead to concern overlap so we must be careful, but in
general, I see some great value on this.
> (6) Handle form submits?
>
> Yes. Default target of a form submit is always the current page (=state)
> itself.
YES! This is a conclusion that I drew as well.
> The FlowHandlerAction checks if there's an event parameter
> triggering a transition leading to another state (according to the state
> and transition description in the Transition Map) or if there is no
> matching event parameter and the page itself has to be generated.
>
> (7) Support generation of forms?
>
> Yes, this is possible in combination with flows, but not implemented
> yet. Using a form descriptor similar to the <parameters> element of the
> transition description in the Transition Map, forms can be generated in
> a unified way, with the default form submit target being the current
> page.
This should definately work closer with Berin's project on XForm.
Probably he'll have more things to say on this.
> -------------------------------------------------------------
> How does this proposal fit into the future plans for Cocoon?
> -------------------------------------------------------------
> That's a point pretty hard to answer for me, because I cannot sneak in
> the heads of the Cocoon front row developers. All I could do is point
> out the aspects we've been considering. Now it's your turn, please throw
> your stones. ;-)
>>From what I can see (a superficial global view), I love it. Really, I
think there is some great innovation and very well designed.
I think you also considered a high priority to use the existing
framework without changing things, but I repeat that I'd like to shoot
for elegance at this point than back compatibility, expecially for such
an important thing.
So, good job, welcome aboard and let's keep beating the iron.
Ciao.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org