Re: [RT] flow machinery

[Torsten Curdt]

and find that the old doc (at new URL:
http://wiki.apache.org/cocoon/GeneralizedFlow, ever so unreadable as
back then) still holds some ideas worth considering, no?

...forgotten gems :) Definitely!
I have to read up on this.

for one: the possibility to have more then one 'flowEngine' as you call

it available inside one sitemap would be neat

Ah! Yes! ...that bugged me as well. Forgot it on the write up.
Why would you need to define multiple scripts per flow defined
inside the sitemap? Which one are you referring to when you
call the function?

  <map:flows>
    <map:flow type="my-flow"        language="java"       src="..."/>
    <map:flow type="my-second-flow" language="java"       src="..."/>
    <map:flow type="my-third-flow"  language="javascript" src="..."/>
  </map:flows>

One of the points of the wiki page was appealing on the first glance
and turned into another RT: it might be a good idea to remove the
stigmata from actions and join the concepts a bit more. IMHO having
map:act *and* map:call is not really nice.

  <map:call action="my-action" function="function-name"/>

  <map:call flow="my-flow" function="start-of-flow"/>

  <map:call continuation="{1}" />

Something better would be even to handle a flow without "sending"
a page as an action. So users would not have to think about whether
it is an action or a flow. Of course this blurs the contracts a bit

WDYT?

<map:call action="my-action"/> <!-- defaulting to the current default method --> <map:call function="start-of-flow"/> <!-- ok if there is only one flow defined -->

(and there were some more related re-naming suggestions for the sitemap

syntax as well IIRC, maybe the future of a 2.2 release offers us the
fork to concider some of that as well?)

Fork?


As long as we provide an easy way to migrate we should be able to shape
*everything* in trunk into a forward direction.

If we cannot change things like this, the contract of trunk is too tight IMO.

From a pure web/REST/temp resource POV I still like the idea of having
dynamic URI's that can be shared between end users (thus regardless of
their session) is kinda cool (think chatrooms/operators assisting in

even safer then just having it de facto available)

'your' flow), but I think this kind of use could also be solved by smart redirects and some application level 'resource' management (probably be

Hm... but they would not assist in your flow ...they can only start
off where you left off and continue in a new tree of continuations.
Could you offer a more concrete example?

cheers
--
Torsten

PGP.sig
Description: This is a digitally signed message part