cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoon Input Model
Date Mon, 01 Mar 2004 18:32:44 GMT
Alan wrote:

> * Hunsberger, Peter <> [2004-03-01 16:17]:
>>Steve Krulewitz <> writes:
>>1) in the flowscript the varible "output" has the complete contents of
>>this pipeline in it, it can be folded back into any handling you want
>>via flowscript variable passing (eg, as an XSLT parameter containing a
>>2) if you don't want to use a parameter you can also pick the contents
>>of this pipeline back up via xmodule input/output handling which is what
>>we do (the xmodule destination above). BTW, I keep meaning to thank
>>Daniel for this: thanks Daniel! 
>>So, bottom line, I don't think Cocoon needs any new sitemap constructs
>>to do what is being discussed, unless what is needed is a way to do this
>>without flow?  However, trying to do this without flow seems to me to
>>mean going back to regular actions, so I can't see any real reason to do
> I think what is needed is a way to do the following without flow.
>     deserialize -> validate -> store -> generate -> serialize
>     The thread started with the notion that input would become XML,
>     not JavaScript structures.
> I'm not sure what regular actions were. A bad thing I suppose.
>     Perhaps because they were catch all constucts?
>     I think there is a common idiom that can be expressed as XML.
>     The sitemap becomes far too difficult to read if the
>     relationships between pipelines are absent from the sitemap.

Been there, done that: it doesn't work.

It's the 80/20 rule: 20% of the job requires 80% of the energy/time.

What you are describing is a model that is highly simplicistic and 
cannot be generalized enough.

Look, nobody prevents you from doing this already today:

  StreamGenerator -> ValidateTransformer -> StoreTransformer ->

but then what happens if the validation is not complete? how to you 
manage that? what is the logic?

Pretty soon you start doing

  StreamGenerator -> ValidateTransformer -> Selector -> ...

to understand the various types of errors and the complexity of this 
gets worse and worse over time and you start to realize that your 
simplicistic mental model was not mapping with real life very well.

This is exactly why we have flow.

And this is why flow is the way to go: it scales with the procedural 
complexity while the sitemap does not.

Whether is javascript or java or lisp is an different story entirely and 
we can discuss this, but one thing is for sure: I will be strongly 
opposed in adding more procedurality to the sitemap unless there is a 
strong reason.

And I haven't seen one yet.


View raw message