* Hunsberger, Peter <[EMAIL PROTECTED]> [2004-03-01 16:17]:
Steve Krulewitz <[EMAIL PROTECTED]> 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 nodeset).
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 this...
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.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
