Stefano Mazzocchi wrote:


<snip/>



This smells awefully close to "dynamic pipelines" which is something that is considered an anti-pattern in cocoon (because it has been tried in the 1.x generation and miserably failed).

People see the pipeline machinery and think they can do things like SOAP validation with it... well, it's not designed for that.
well that's what happens when people find a shiny new hammer - all they see are nails :)


A while ago there was the proposal of "content-aware selectors" that would allow you to implement what these guys want, I know that there is also an implementation floating around even if we never reached consensus on whether or not that was a good thing to have.


What you are proposing is "context-dependent behavior"... well, this is
well it's context-dependent behavior yes - but implemented in a context independent way.

*exactly* what we are trying to avoid with pipelines: reusability of the component is focused to be completely independent of the place where it is used in the pipeline. Make the component "location dependent" and kiss goodbye to orthogonality, and pretty soon you need a language that
wasn't the guy trying to achieve the opposite? He wanted to be develop a component that he could plug anywhere because it autonomously finds out about the pipeline structure it's embedded in. Is that then "location" dependent because it needs to find out about it's location or "location independent" because it finds out about it's location and acts automagically. I'm confused now.

indicates the potential 'neightbours' of each component... and maybe people would want to add conditionals to that language... and pretty soon people will ask you to deparate the cross-cutting pipeline concerns into pipeline interceptors... and so on.
i see your point though here.

Regards
Jorg



Reply via email to