Alexander Klimetschek wrote: > On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger <[email protected]> > wrote: >> There is yet another alternative, which also sounds intriguing: We >> define a ScriptEngineFactory for the ".pipeline" extension. Files with >> the extension .pipeline would be pipeline configurations, which would be >> interpreted by the PipelineScriptEngine. The second part of the >> processing -- preparation of the input data -- would be analogous to the >> above with the two options : >> >> /a/b/data >> +-- sling:resourceType = "sling/pipeline/sample" >> >> /apps/sling/pipeline/sample/html.pipeline >> "file with pipeline config" > > I like this one more. > > For the question how the initial XML (or whatever stream the pipeline > can handle) is generated: that should be part of the pipeline > config/script, using standard generators just as in Cocoon for > example. I could imagine a XML generator that simply does an xml > document view of the node in question. > Yes, I totally agree here as well :) This sounds like the nicest approach.
However whereas this is one important use case I see another use case where I simply want to "run" a pipeline on generated output of some script like for doing link checking or doing other general purpuse stuff. In this case the sling:resourceType would still point to the original script doing the html representation and the pipeline would take the (html) output and process it. Not sure if we can find a good solution for this as well. But we can have a look at the first use case first and then see where this leads. Carsten -- Carsten Ziegeler [email protected]
