Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4005169F.3010806@outerthought.org>
Date: Wed, 14 Jan 2004 11:14:55 +0100
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Flow or actions?
References: <E37F8F79E39C0943A8E2846F1C4EA9F2082A0931@mail003.unimaas.nl>
In-Reply-To: <E37F8F79E39C0943A8E2846F1C4EA9F2082A0931@mail003.unimaas.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


H.vanderLinden@MI.unimaas.nl wrote:

> Although most of the arguments are clear, they also raise more questions :-)
> 
> 
>>I don't know if I get all arguments but at least some:
>>1. Both actions and flow scripts were designed for the 
>>controller part.
>>2. Actions were often misused, so a new concept was searched for.
> 
> 
> Could you give an example of this "misuse"?
> 

hm, as I see things (and there are many opinions I'm afraid) you should 
look at Actions as being the equivalent of 'static' methods in Java

they apply to all your users in the same way, and the 'instance' data 
they need to maybe work upon to do user-sepcific stuff needs to be 
stored/collected from the session all the time

conceptually 'flow' often seems to have it's own instance data (i.e. not 
be strictly stateless)
solving these cases in a classic web programming paradigm forces you to 
put that information over in the session, complicating your strict 
use-case-controller by adding both session store/lookup instructions and 
extra stress to manage that session object well (avoiding 
attribute-key-conflicts)

to me deciding between both is similar to deciding between static or not 
in Java. Equally the classic Java-advice 'avoid static when unsure' 
should be extended to this area: choose flow (and sendPageAndWait) over 
actions

HTH even if the explanation is not technically conclusive (there is some 
emotions and personal feeling/vision around this, so be sure to develop 
your own and be open enough to test it regularly in real life cases)

> 
>>3. Interpreting (flow script) vs. compiling (actions).
>>4. Procedural style of the flow scripts is nearer to flow control.
>>5. Support of continuations with flow scripts.
> 
> 
>>>From a newbie point of view: the idea behind it is fairly easy to grasp, but
> when trying to figure out why it doesn't work as expected (e.g. with Woody
> forms) it is very incomprehensible. But maybe that is related to 6.
> 

hm, my guess would be it has more to do with experience and feeling 
comfortable, knowing your way around...

this might help a bit: 
http://cocoon.apache.org/2.1/howto/howto-flow-debugger.html

but doing some print() statements often helps fast to nail it down

> 
>>6. Less delivered code for flow scripts while there are many actions 
>>available.
>>7. Better separating of concerns for flow scripts.
>>8. Therefore less sitemap readibility (the sitemap flow is not that 
>>obvious, because parts of the logic is in the flow script).
> 

hm, probably 'non-exclusive-role of the classic sitemap in deciding the 
pipeline to use' might be a more political correct (opinion neutral) 
transcription of point 8 :-)

> 
> Thanks for the explanation. Can you, or anyone else, give ideas as to when
> to use actions and when to use flow? I don't have the feeling that they are
> interchangeable. On the other hand I feel that using both actions and flow
> in a single webapp will add to the complexity.

see above: understand what they are good at, consider the flow solution 
first (and just don't consider anything else if there is 'flow' or 
end-user interaction to control in your use case)

flowscripts without own variables or sendPageAndWait (or showForm) are 
candidates to be reconsidered... (if there is even no backend to connect 
then matchers, selectors or input-modules might be an even better choice)

> 
> Bye, Helma
> 

regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org