Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FB2C5CD.5000201@virbus.de>
Date: Thu, 13 Nov 2003 00:44:13 +0100
From: Joerg Heinicke <jheinicke@virbus.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [vote] forbidding flowscripts with no sendpage redirects (was
 Re:   Saving pipeline output to a temp file...)
References: <3FB279F2.18467.1886D8C@localhost>
In-Reply-To: <3FB279F2.18467.1886D8C@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 13.11.2003 00:20, Andrzej Jan Taramina wrote:

>>  <map:match pattern="*/profile/edit">
>>    <map:call function="dumpData"/>
>>  </map:match>
>>
>>  <map:match pattern="view">
>>    <map:generate src="cocoon://generate"/>
>>    <map:transform src="homePage.xsl"/>
>>    <map:serialize/>
>>  </map:match>
>>
>>function dumpData() {
>>   dumpUserData();
>>   dumpOrderData();
>>   dumpNewsItems();
>>   cocoon.sendPage("view");
>>}
>>
> 
> 
> The main problem I have with this approach is that without looking at the 
> script code, there is no easy way of telling that the first match will end up 
> calling the second one and so the flow of the application becomes more 
> opaque...and thus harder to understand and maintain.
> 
> I like Tim's approach much better....where everything is in one place and the 
> high level flow of control is quite clear and transparent.

For the moment it's better to have this that restrictive. But have a 
look at the recent thread "[RT] Is flowscript polluting sitemap 
readability?". Maybe, but really only maybe as it was only a random 
thought and we must think about the concept, there will be a Selector in 
the future that leads the sitemap flow depending on the result of the 
flow script. This brings the light back to the sitemap and can reduce 
opaqueness ;-)

And this will remove the need for such an action-like behaviour you and 
Tim relied on. BTW what exactly should the FlowAction do? I didn't 
follow the thread closely. If it does that what I imagine (or fear) we 
are back to actions and don't need any flow. I like the Selector 
approach much more. But let's discuss it at that thread.

Joerg