Pipeline support
Hi, In response to this thread [1] in the Apache Cocoon Dev list, I have been working in a minimal sample [2] concerning about resolution of pipelines and Apache Sling. IMHO, having pipeline support in Sling is an important feature in terms of separation of concerns. On the other hand, because it´s important not reinventing the wheel, IMHO we should take advantage of Cocoon community efforts somehow or other. Right now, the Cocoon team is working in a new and refactored framework´s release named Cocoon 3. AFAIK, this release is intended to be a more minimal version of Cocoon 2.2 and IMHO more suitable to be integrated into Sling. For the time being (alpha-1), Cocoon artifacts are not released as OSGi bundles. The stuff [2] is just a proof of concept using Cocoon 3 pipelines inside Sling but with the current state of art, that is, without changes in Sling core. Nevertheless, IMHO Sling should have a more natural pipeline support with Cocoon pipeline definitions as Sling scripts. Until now, dynamic resources have been rendered with two kinds of animals: servlets and scripts. What about having pipelines as a new kind of animal?. Comments and ideas are welcome. BR, Juanjo. [1] http://markmail.org/message/owefsfj4eqbc4ifq#query:OSGi%20integration%20(again)%20markmail+page:1+mid:owefsfj4eqbc4ifq+state:results [2] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jvazquez/pipeline
Pipeline support
Hi all, After some work, the pipeline support prototype [1] has ended up as follows: 1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl" extension. For instance: http://www.w3.org/ns/xproc";> 2. The pipeline (xpl file) is interpreted by a scripting engine named "XProc" or "XML pipeline processor". 3. The XProc script engine relies on Cocoon 3 Pipeline in order to setup and execute the pipeline. 4. A Cocoon generator named SlingGenerator is responsible for preparing the input data. In order to get the initial XML for the pipeline, the generator tries to resolve the current resource as: * a XML file (adapting to InputStream) * dynamically generated XML (using an inclusion procedure) * the underlying node´s export document view 5. A Cocoon transformer named SlingTransformer is responsible for resolving XSLT templates. If you are agree with this approach, I´d like grabbing the stuff into trunk after adding some unit testing. The question is, where?, "bundles/scripting" or "contrib/scripting"?. WDYT?. BR, Juanjo. [1] https://svn.apache.org/repos/asf/incubator/sling/whiteboard/jvazquez/org.apa che.sling.scripting.xproc [2] http://www.w3.org/TR/xproc/
Re: Pipeline support
Hi, Juan José Vázquez Delgado wrote: > Hi, > > In response to this thread [1] in the Apache Cocoon Dev list, I have > been working in a minimal sample [2] concerning about resolution of > pipelines and Apache Sling. IMHO, having pipeline support in Sling is > an important feature in terms of separation of concerns. Yes, definitly and thanks for sharing your code! I wasn't able to look at it yet :( > On the other hand, because it´s important not reinventing the wheel, > IMHO we should take advantage of Cocoon community efforts somehow or > other. Definitly. > > Right now, the Cocoon team is working in a new and refactored > framework´s release named Cocoon 3. AFAIK, this release is intended to > be a more minimal version of Cocoon 2.2 and IMHO more suitable to be > integrated into Sling. For the time being (alpha-1), Cocoon artifacts > are not released as OSGi bundles. Yes, not yet - and with the current package layout in C3 it wouldn't work. But I'll take care that we will have proper bundles in the end. Hopefully alpha-3 will have OSGi bundles. > The stuff [2] is just a proof of concept using Cocoon 3 pipelines > inside Sling but with the current state of art, that is, without > changes in Sling core. > > Nevertheless, IMHO Sling should have a more natural pipeline support > with Cocoon pipeline definitions as Sling scripts. Until now, dynamic > resources have been rendered with two kinds of animals: servlets and > scripts. What about having pipelines as a new kind of animal?. There are two possibilities: Either make a pipeline a script, or let a script (jsp, groovy etc.) generate xml and use a pipeline for postprocessing. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Pipeline support
> There are two possibilities: > > Either make a pipeline a script, or let a script (jsp, groovy etc.) > generate xml and use a pipeline for postprocessing. In fact, my sample is in line with your second option. The XSL templates are retrieved from resources, too. Juanjo.
Re: Pipeline support
Hi Juanjo, Juan José Vázquez Delgado schrieb: > In response to this thread [1] in the Apache Cocoon Dev list, I have > been working in a minimal sample [2] concerning about resolution of > pipelines and Apache Sling. IMHO, having pipeline support in Sling is > an important feature in terms of separation of concerns. Agreed. > On the other hand, because it´s important not reinventing the wheel, > IMHO we should take advantage of Cocoon community efforts somehow or > other. > > Right now, the Cocoon team is working in a new and refactored > framework´s release named Cocoon 3. AFAIK, this release is intended to > be a more minimal version of Cocoon 2.2 and IMHO more suitable to be > integrated into Sling. For the time being (alpha-1), Cocoon artifacts > are not released as OSGi bundles. > > The stuff [2] is just a proof of concept using Cocoon 3 pipelines > inside Sling but with the current state of art, that is, without > changes in Sling core. > > Nevertheless, IMHO Sling should have a more natural pipeline support > with Cocoon pipeline definitions as Sling scripts. Until now, dynamic > resources have been rendered with two kinds of animals: servlets and > scripts. What about having pipelines as a new kind of animal?. > > Comments and ideas are welcome. I think your approach is very lightweight (which is good) and straightforward. 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. 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. How about turning this around and have the pointer to the pipeline definition in the data resource, as in: /a/b/data +-- sling:resourceType = "sling/pipeline" +-- sling:pipeline = "/the/path/to/the/pipeline" /the/path/to/the/pipeline +-- sling:definition = [ "step one", "step two" ] You then request the /a/b/data resource which causes the PipeLineServlet to kick in and construct the pipeline from the pipeline definition at /the/path/to/the/pipeline. The pipeline definition can be as complex as it need be (I am not fluent with this enough, to make a full judgement). Now, the question is: How to generate the initial (XML) data stream for the pipeline ? Here I would take a two-option approach, both involving a custom AbstractGenerator: * option 1: there is a sling:pipelineResourceType property. This is used to render the data resource and use the result as input for the pipeline: The pipeline servlet would include the processing of the resource overwriting the sling:resourceType with the value of the sling:pipelineResourceType. * option 2: there is no sling:pipelineResourceType property: Here the data resource contains the XML to be processed. You would then adapt the resource to an InputStream and used that directly as the input for the pipeline. 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" WDYT ? Regards Felix
Re: Pipeline support
On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger 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. Just my 2 cents... Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Pipeline support
Alexander Klimetschek wrote: > On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger > 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 cziege...@apache.org
Re: Pipeline support
Hi, Carsten Ziegeler schrieb: > Alexander Klimetschek wrote: >> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger >> 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
Re: Pipeline support
On Tue, Feb 10, 2009 at 2:52 PM, Felix Meschberger wrote: >> 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 ? +1 I don't know what the latest state of the discussion of a generic filter mechanism is that also includes the ability to use scripts as filters. I think the simplest thing would be if scripts for filters would resolved just as scripts for the main "rendering". Then the .pipeline script type can be used for both use cases. The open question is probably how the "interface" for such a filter script looks like. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: Pipeline support
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.
Re: Pipeline support
> 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. Until now, I have just been thinking about XSL based transformers acting over generated XML. BR, Juanjo.
Re: Pipeline support
Hi Juanjo, Juan José Vázquez Delgado schrieb: > Thanks for your smart response. .. and thanks for the flowers ;-) > [snip] >> 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). I fear, I do not understand this sentence. > > 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?. Right, AFAICT. Regards Felix
Re: Pipeline support
>> On the other hand, IMHO the datasources would be into the "content >> resource" as properties (/a/b/data in your proposal). > > I fear, I do not understand this sentence. Sorry, I mean, I don´t know if all data you need in order to compose the first XML (pipeline generator) would be resource´s properties as a must condition. BR, Juanjo.
Re: Pipeline support
Hi, Juan José Vázquez Delgado schrieb: >>> On the other hand, IMHO the datasources would be into the "content >>> resource" as properties (/a/b/data in your proposal). >> I fear, I do not understand this sentence. > > Sorry, I mean, I don´t know if all data you need in order to compose > the first XML (pipeline generator) would be resource´s properties as a > must condition. Yes. I think there are multiple options for the input * apply standard Sling processing as in RequestDispatcher.include(resource, resourceTypeOverWrite) * take the "contents" as in Resource.adaptTo(InputStream) * take the XML-Export (docview probably) in order of preference. Regards Felix > > BR, > > Juanjo. >
Re: Pipeline support
Hi Felix, > Yes. I think there are multiple options for the input > > * apply standard Sling processing as in > RequestDispatcher.include(resource, resourceTypeOverWrite) I´m not sure what you mean with this case. I understand, the pipeline source would be the XML expressed result of resolving another Sling resource. Right?. We´d have something like this: RequestDispatcher dispatcher = request.getRequestDispatcher(generatorResourceAbsPath); dispatcher.include(request, response); > * take the "contents" as in Resource.adaptTo(InputStream) > * take the XML-Export (docview probably) These other cases would act over the current resolved resource, right?. In the other hand, I´m thinking about implementing a partial (or total) support for XProc [1] and using cocoon-pipeline [2] behind the scenes. WDYT? BR, Juanjo. [1] http://www.w3.org/TR/xproc/ [2] http://svn.eu.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-pipeline
Re: Pipeline support
Hi guys, Last days, i have been working on a new prototype about a certain kind of XML pipelines support in Sling [1]. The prototype is making these main assumptions: 1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl" extension. For instance: http://www.w3.org/ns/xproc";> http://localhost:/xpl-sample/xsl/test-content.xslt"/> 2. The pipeline (xpl file) is interpreted by a scripting engine named "XProc" or "XML pipeline processor". 3. The XProc script engine relies on Cocoon 3 Pipeline in order to setup and execute the pipeline. 4. A Cocoon generator named SlingGenerator is responsible for preparing the input data. 5. A Cocoon transformer named SlingXsltTransformer will be responsible for resolving XSLT templates. Now, my main problem is the point 4. Because of the generator needs an InputStream with XML data, my first approach was: /apps/sling/xpl/sample/html.xpl /xpl-sample/pipelines/test_pipeline +-- sling:resourceType: "sling/xpl/sample" +-- sling:datasource: "/xpl-sample/test.xml" /xpl-sample/test.xml private InputStream genXml() throws Exception { Resource resource = request.getResource(); Map props = resource.adaptTo(Map.class); String absPathGen = props.get("sling:datasource").toString(); Resource genResource = request.getResourceResolver().resolve(absPathGen); return genResource.adaptTo(InputStream.class); } This is ok if my data source is a XML file but, what happens if we have another reource type?. For instance, I´d like been able to generate XML data source as a result of executing a script. I tried this, in a similar way that "SlingRequestDispatcher include" works, but I didn´t succeed. Any ideas?. Thanks in advance, BR, Juanjo. [1] https://svn.apache.org/repos/asf/incubator/sling/whiteboard/jvazquez/org.apache.sling.scripting.xproc [2] http://www.w3.org/TR/xproc/
Re: Pipeline support
Though I am late to this discussion, taken an excerpt form previous discussion "I could imagine a XML generator that simply does an xml document view of the node in question." [ An excerpt from previous discussion] then using *something to process the document, into something Wouldn't E4X be a viable alternative in this situation? for example you could write (output) your links and name of links into an HTML then use an HTML parser to crawl and check the links...WDYT? http://wiki.eclipse.org/E4/JavaScript Ransford Segu-Baffoe paks...@yahoo.com http://www.noqmx.com/ https://serenade.dev.java.net/ --- On Tue, 2/10/09, Carsten Ziegeler wrote: From: Carsten Ziegeler Subject: Re: Pipeline support To: sling-dev@incubator.apache.org Date: Tuesday, February 10, 2009, 8:46 AM Alexander Klimetschek wrote: > On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger 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 cziege...@apache.org
Re: Pipeline support
Hi Juanjo, On Tue, Mar 10, 2009 at 9:47 AM, Juan José Vázquez Delgado wrote: > ...After some work, the pipeline support prototype [1] has ended up as > follows:... Cool stuff! Still haven't tested it, shame on me...but your description looks great. Just two quick comments for now. > ...1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl" > extension Is this "xpl" extension standard? If you're choosing your own I'd prefer not having an L at the end as it's too easy to confuse with a I. Maybe "xpr" or even "xproc", clearer? > ...If you are agree with this approach, I´d like grabbing the stuff into trunk > after adding some unit testing... +1 > ...The question is, where?, "bundles/scripting" or "contrib/scripting"?. We recently said "everything new initially goes under contrib", I think that's good in this case. Although very useful, this is not core Sling functionality. -Bertrand
Re: Pipeline support
>> ...1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl" >> extension > > Is this "xpl" extension standard? > If you're choosing your own I'd prefer not having an L at the end as > it's too easy to confuse with a I. > Maybe "xpr" or even "xproc", clearer? This has been extracted from the XProc candidate recomendation [1]. Literally: "The media type for pipeline documents is application/xml. Often, pipeline documents are identified by the extension .xpl." I suppose we are not forced to use this extension but IMHO it could be a good idea to stay in line with the recomendation. Anyway, we can support both of them. >> ...If you are agree with this approach, I´d like grabbing the stuff into >> trunk >> after adding some unit testing... > > +1 > >> ...The question is, where?, "bundles/scripting" or "contrib/scripting"?. > > We recently said "everything new initially goes under contrib", I > think that's good in this case. > Although very useful, this is not core Sling functionality. Agreed. BR, Juanjo.
Re: Pipeline support
> This has been extracted from the XProc candidate recomendation [1]. Sorry, I forgot the link: [1] http://www.w3.org/TR/xproc/
Re: Pipeline support
On Tue, Mar 10, 2009 at 10:43 AM, Juan José Vázquez Delgado wrote: >>> ...1. A XML pipeline is expressed as a W3C XProc [2] file with "xpl" >>> extension >> >> Is this "xpl" extension standard? >> If you're choosing your own I'd prefer not having an L at the end as >> it's too easy to confuse with a I. >> Maybe "xpr" or even "xproc", clearer? > > This has been extracted from the XProc candidate recomendation [1]. > Literally: "The media type for pipeline documents is application/xml. > Often, pipeline documents are identified by the extension .xpl." Fine then, let's go with the standard! -Bertrand
[jira] Created: (SLING-893) Pipeline support
Pipeline support Key: SLING-893 URL: https://issues.apache.org/jira/browse/SLING-893 Project: Sling Issue Type: Improvement Components: Extensions Affects Versions: 3 Reporter: Juan Jose Vazquez Delgado Assignee: Juan Jose Vazquez Delgado As discussed in [1] we should have some sort of pipeline support in Sling. This stuff will be provided as a contrib or extension. [1] http://markmail.org/thread/33h5nhk5e3mswrue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-893) Pipeline support
[ https://issues.apache.org/jira/browse/SLING-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-893: -- Component/s: (was: Extensions) Xproc > Pipeline support > > > Key: SLING-893 > URL: https://issues.apache.org/jira/browse/SLING-893 > Project: Sling > Issue Type: Improvement > Components: Xproc >Affects Versions: 3 >Reporter: Juan Jose Vazquez Delgado >Assignee: Juan Jose Vazquez Delgado > Original Estimate: 0h > Remaining Estimate: 0h > > As discussed in [1] we should have some sort of pipeline support in Sling. > This stuff will be provided as a contrib or extension. > [1] http://markmail.org/thread/33h5nhk5e3mswrue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-893) Pipeline support
[ https://issues.apache.org/jira/browse/SLING-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Jose Vazquez Delgado resolved SLING-893. - Resolution: Fixed First version in [1]. Close this issue and open new ones for bugs and enhancements. [1] http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc > Pipeline support > > > Key: SLING-893 > URL: https://issues.apache.org/jira/browse/SLING-893 > Project: Sling > Issue Type: Improvement > Components: Xproc >Affects Versions: 3 >Reporter: Juan Jose Vazquez Delgado >Assignee: Juan Jose Vazquez Delgado > Original Estimate: 0h > Remaining Estimate: 0h > > As discussed in [1] we should have some sort of pipeline support in Sling. > This stuff will be provided as a contrib or extension. > [1] http://markmail.org/thread/33h5nhk5e3mswrue -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Pipeline support - update with right link
Though I am late to this discussion, taken an excerpt form previous discussion "I could imagine a XML generator that simply does an xml document view of the node in question." [ An excerpt from previous discussion] then using *something to process the document, into something Wouldn't E4X (links below) be a viable alternative in this situation? for example you could write (output) your links and name of links into an HTML then use an HTML parser to crawl and check the links...WDYT? https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Processing_XML_with_E4X https://developer.mozilla.org/En/E4X Ransford Segu-Baffoe paks...@yahoo.com http://www.noqmx.com/ https://serenade.dev.java.net/ --- On Tue, 2/10/09, Carsten Ziegeler wrote: From: Carsten Ziegeler Subject: Re: Pipeline support To: sling-dev@incubator.apache.org Date: Tuesday, February 10, 2009, 8:46 AM Alexander Klimetschek wrote: > On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger 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 cziege...@apache.org
Re: Pipeline support - update with right link
On Fri, Feb 20, 2009 at 5:10 AM, paksegu wrote: > Though I am late to this discussion, taken an excerpt form previous discussion > > "I could imagine a XML generator that simply does an xml document view of the > node in question." [ An excerpt from previous discussion] > > then using *something to process the document, into something > > Wouldn't E4X (links below) be a viable alternative in this situation? for > example you could write (output) your links and name of links into an HTML > then use an HTML parser to crawl and check the links...WDYT? > > https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Processing_XML_with_E4X > > https://developer.mozilla.org/En/E4X For the generator of the pipeline it should be possible to use any normal sling script, because they already run on top of the data (a node/resource) and generate a stream. If there would be a scripting engine capable of E4X, one could simply use it as generator. Regarding scripts for all the parts of a pipeline: For the other elements of the pipeline (transformers and serializers) the input interface is a bit more difficult as they will have to deal with an input stream. In Cocoon, these pipelines are based on standard SAX events, which is probably not that easy to "script". Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com