Hi, Carsten Ziegeler schrieb: > Alexander Klimetschek wrote: >> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger <fmesc...@gmail.com> >> 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.
This kind of post-processing would probably best be placed into a Servlet Filter ? Regards Felix
