cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [RT] flow machinery
Date Wed, 26 Oct 2005 16:40:26 GMT
> 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 action="my-action"/> <!-- defaulting to the current  
default method -->
   <map:call flow="my-flow" function="start-of-flow"/>
   <map:call function="start-of-flow"/> <!-- ok if there is only one  
flow defined -->
   <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?


> (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?

If we cannot change things like this, the contract of trunk is too  
tight IMO.
As long as we provide an easy way to migrate we should be able to shape
*everything* in trunk into a forward direction.

> 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
> 'your' flow), but I think this kind of use could also be solved by  
> smart
> redirects and some application level 'resource' management  
> (probably be
> even safer then just having it de facto available)

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

Mime
View raw message