cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RT] Is flowscript polluting sitemap readability?
Date Wed, 12 Nov 2003 13:39:48 GMT

On 11 Nov 2003, at 15:48, Geoff Howard 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

  2) criticizing the sitemap/flowscript separation

As for the first one, I think we have consensus (no -1 were expressed): 
it is better to tighten up sooner rather than later. We can always open 
up later on. This makes transitions less painful for everyone.

As for #2, the issue is completely different and requires an entirely 
different reasoning. But it's important so let's do it.

>  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"/>
   <read src="error.html"/>

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 

> 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...

  <call function="blah">

but this has one major limitation: the flow can call one and only one 
pipeline. If we reintroduce the super-ugly action-like syntax and we 

  <call function="blah">

then we allow the flow function to call "two" pipelines... but what 
happens if the flow function calls sendPage*? the above gives a *false* 
impression of readability... but the flow might be much more complex 
than this (expecially with continuations!!).

An alternative could be

  <call function="blah">
    <pipeline name="whatever">
    <pipeline name="something_else">

and then flow should be restricted from calling general pipelines but 
would only be able to call the ones "scoped" inside its call. For sure 
it would be more procedural... but would it be more readable? And what 
if I want to share the same pipeline with more calls? we could create 
pipeline symlinks for external ones

  <call function="blah">
    <pipeline name="whatever">
    <pipeline name="something_else" maps-to-uri="foo/bar/{param}/>

Doable. But would it help?

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".

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)

> So actually, I'll say I'm -.5 on the need to enforce this at all.

As a rule, we should restrict everything that we can't come up with a 
reason to make it possible, then keep listening for people that could 
come up with those reasons.

Today, no reason has been proposed, so it's good to close it.

Allowing something just for the sake of freedom has harmed us in the 
past (expecially in the migration to the treeprocessor), so we 
shouldn't allow further harm.

> --

View raw message