cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <jheini...@virbus.de>
Subject Re: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Date Wed, 12 Nov 2003 23:44:13 GMT
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


Mime
View raw message