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
|