Thanks for your smart response. > I think your approach is very lightweight (which is good) and > straightforward.
That´s right. My goal was having a sample as much as simple as possible. > The problem I see, is that you actually need two > resources (you don't need a Node if you do resource.adaptTo(Map.class), > which gives you the properties you need): One provides the actual > content to be processed and one defining the pipeline and pointing to > the content to be processed. Agreed. I don´t like this requirement either. > The problem is not merely, that there are two resources involved, the > problem to me is the pointer from the pipeline definition to the data > source to be processed. Sure, that is the point. > 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" Definitely this is my favourite one among your proposals. With this approach we have a clear separation between content and presentation as well as keep the typical resolution way in Sling. Great!. On the other hand, IMHO the datasources would be into the "content resource" as properties (/a/b/data in your proposal). This approach is close to the idea about treating pipelines like regular scripts. There will be nice to have pipeline definitions in a Cocoon way (like they are in the sitemap.xml). WDYT?. BR, Juanjo.
