cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [RT] Is flowscript polluting sitemap readability?
Date Wed, 12 Nov 2003 18:49:39 GMT
On 12.11.2003 14:39, Stefano Mazzocchi wrote:

>> I'm the same.  In fact, I think that flow in some cases needlessly 
>> complicates the composition of a pipeline.  Now I have to have two 
>> pipelines where I used to need one.
> wait wait wait. hold it.
> There are different issues on the table here:
>  1) applying the good old "strict first, open later if needed" pattern 
> to flowscript/sitemap interaction

That's absolutely okay and I don't have any problems with it.

>  2) criticizing the sitemap/flowscript separation

But here ...

>>  I have to have one that matches the external request and calls the 
>> flow function, and another one for the default result of that 
>> pipeline.  So far this has felt like needless additional complexity to 
>> me (and I think will to others).
>> To try to make this point a little clearer:
>> Part of the beauty of the sitemap prior to flow was that you could at 
>> a glance see what each request url was triggering.
> Look at this pipeline:
>  <match pattern="**">
>   <act type="my_own_action">
>     <generate src="{param1}.{type1}"/>
>     <transform src="{type1}2html.xslt"/>
>     <serialize/>
>   </act>
>   <read src="error.html"/>
>  </match>
> when is the error triggered? What is the above supposed to do? I know 
> the example sounds rather artificial, but if you look around in the more 
> complex uses of actions (the portal framework, for example, or Lenya) 
> you see that 'readability' is not really improved the sitemap by itself.

No, the action flow is also not really good and obvious. It works only 
if you know exactly what an action is doing. Good naming like 
resourceExists does help, but not more. Naming conventions do not 
replace the restrictiveness of a good approach as I already said in my 
reply to Antonio's mail.

>> Now, I look at the sitemap, have to locate the flowscript, parse 
>> through it for the various sendPage etc. and then back to the sitemap 
>> to find where the action really happens.  This could perhaps be 
>> handled with some best practice naming conventions.  Perhaps a 
>> practice of passing in the various possible view uris to the 
>> flowscript should be considered.  I don't know.
> Flowscript makes the sitemap more declarative and allows to move the 
> logic away from the sitemap and leaves the sitemap with pipelines that 
> are either "called" by the servlet or from its internal.
> Note that not only flowscript allowed this "declaritization", but 
> followed the "cocoon:" protocol in doing so.
> Is this intrinsically less readable than an action? no, it just moved 
> the readability in another place.
> Vadim suggested the introduction of action-like syntax to allow to see 
> exactly where you end up being...

No, I absolutely don't like it, in what form ever. We would introduce 
the same problems as for actions.

<snip what="action-like syntax"/>

> It looks a lot like design patterns for XSLT: xslt is not hard to write 
> *per se* (for a programmer, I mean, once you understand it)... but it's 
> hard to find "good stylesheets" and it's hard to debug them because it's 
> hard to see the "instruction flow"... since it's a declarative rule engine.
> The sitemap goes in that direction. It is becoming more and more 
> declerative regarding request generation and the procedural part has 
> been moved away, locked in the place where it should be easier to read.
> It is true, though, that currently, in the middle of the transition 
> stage, more and more logic is done in the pipeline components that 
> shouldn't be done there! There are tons of transformers and actions 
> doing stuff that should be done at the flowscript level (from accessing 
> a regular java component that gives a specific service)
> But I don't think the model is wrong... it's just that the current 
> component set grew out of the pressure of a different environment with 
> different limitations... flow is going to change this and will also make 
> patterns emerge.
>> I'm not negative on flow, and not positive on actions - just pointing 
>> out a loss of readability of the sitemap that has resulted from our 
>> move forward.
> In italian we say this is the classic "problem of the small blanket": 
> you can't cover everything with one solution, you cover one part and you 
> uncover another.
> It is true that flow separates things and make it harder to understand 
> what pipelines make action of a single resource production. the cocoon: 
> protocol makes thing even worse.
> It is entirely possible to come up with a debugging view of the cocoon 
> execution that shows the trace of all the stages that happened in the 
> creation of a cocoon pipeline. This is something that we'll have to do, 
> also to be able to do a serious "inverted cache".

Understanding code should be possible without debugging it.

> Also, the original sitemap readability is not compromised in case you 
> don't need flow. And if you do, using actions will not make things more 
> readable... just more limited. (it is entirely possible to come up with 
> a flow equivalent of actions that is just as readable, by introducing a 
> simple URI-space pattern for pipeline matching)

Some days ago you complained about bad things in the sitemap like 
actions, resources and ... (don't remember). You suggested to use 
selectors where appropriate and I can only agree with this, because they 
make the sitemap flow really obvious.

Only a random thought: why there is no FlowScriptSelector calling the 
flow script and evaluating the String return type? This would remove the 
  sitemap calls flow script calls sitemap and is more like a function 
call. You will have only one pipeline, not two.


View raw message