Torsten Curdt wrote:
>> 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.
>
just ask for clarification if the doc leaves you puzzled...
let's say there have been people rating it as euh quite 'misty'
>> 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.
>
yeah, when discussing this way back with Sylvain I came up with those
limit-transition ideas showing that actions, apples and
flowscript/javaflow are essentially different faces of the same thing.
It just looks different in some border-line cases.
(a bit like realizing flat Earth is quite spherical if your
look-out-tower is high enough, but without prohibition to still use
practical flat-trigonometrics when your down on the floor again)
and yeah, from there it would be kinda logic to have an alligned syntax
so crossing the borders doesn't come with a new set of (arbitrary)
conventions/line of thinking
note though that historically actions have been used as something
inbetween (stateless)flow-control and input-modules...
> <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
>
not sure if I understand, sample?
> 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?
>
sorry for any confusion, 'fork' was not in the code-versioning meaning
but rather in the sense of 'facilitating tool/event' maybe 'crowbar'
would have been a better word?
> 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.
>
I agree on your statement on _trunk_, I was merely hinting on how we
should call things (i.e. assigned release_num) when we start doing
this... after all we did an effort in making sure our release-numbering
scheme brings a clear message of expected compatibility on various
levels (see http://cocoon.apache.org/versioning.html)
>> 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.
yeah, bummer, ain't it?
2 years ago, putting up a question like this in this group would leave
people to easily conclude that I simply didn't understand the nature of
continuations :-)
Well, I still think I do :-)
I even think I understand the nature of URL's and what they could do,
and if there is a misfit between both that can't be solved, then so be
it, I just like to dream about things...
> Could you offer a more concrete example?
>
I really think stressing these differences could break up the
convergence we're aiming for, and apps like this are porbably very
uncommon anyway
though they might fit very well with the Web 2.0 wave <insert_sound
type="dilbertonian sound of me not believing myself typing this followed
by draconian laughter that keeps little kids awake"/> specially the
social networking stuff I keep hearing about: sounds to me like people
participating in something like 'shared' use cases/flow
but since you ask I'll try making the examples more concrete... (maybe
it offers some ideas and someone sees the light in how to combine all good)
below U1,2 are users firing off HTTP requests
(I'm assuming container does authentication so identification and access
control is taken care of, they're not part of what I want to say)
[chatroom]
U1> POST /chat/make?title=RName > redirects to /chat/room/R_ID
U1> GET /chat/room/R_ID > gets the last 100 messages in the
room, with autorefresh
(getting this right away _could_ create the room even,
although some restonians might well fall over me now)
U1> POST /chat/room/R_ID/talk?msg=Say+hi > adds message to the room
U2> GET /chat/room/R_ID > gets the last...
from here they both join in the same conversation
and the nice part is that people can really invite each other by just
mailing/IMing each other the URL in their browser.
which is of course something the system _can_ help with:
U1> POST /chat/room/R_ID/invite?user=U2
(although I like GET /chat/room/R_ID/invite/U2 as well)
U2> GET /portal/home > arriving or refreshing here he sees
the invitation-URL
[operator assisted form fill in]
bcfs='big complex form-set', think complex flow covering multiple forms
and some conditional branching between them - a monster to do with
anything else then flowscript or javaflow, and even without the willing
assistance of an operator you can call or IM]
U1> GET /bcfs/start > redirects to a new 'instance' of the trail to be
followed, let's call that a trail_id
U1> GET /bcfs/trail_id/step_1
U1> POST /bcfs/trail_id?parameters=... > redirects to next step to take
U1> GET /bcfs/trail_id/step_2
U1> POST /bcfs/trail_id?parameters=... > redirects to next step to take
U1> GET /bcfs/trail_id/step_abc
at this stage the person gets confused and calls in an operator for
assistance
operator asks: where are you (as in 'url in address bar'), and steps in
there:
U2> GET /bcfs/trail_id/step_abc
but the trail_id should be enough as
U2> GET /bcfs/trail_id > redirects to next step to take
the idea is that from here the operator (U2) asks questions and
continues down the path of filling things in, the user could just follow
his trail by pressing F5 (refresh) when he's told to do so
But again, I doubth this theoretical reasoning should prevent us from
taking the logic steps you porpose. I'm quite sure other solutions for
the practical same things can be found... those sollutions would
probably involve adding some extra layer of abstraction in your
application I guess.
Now, it's probably even easy to argue that such extra abstraction in the
architecture is even benefitial for this kind of applications. But it
just wouldn't be an 'option' any more, would it?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
[EMAIL PROTECTED] [EMAIL PROTECTED]
