You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Juan José Vázquez Delgado <ju...@gmail.com> on 2009/02/05 14:18:05 UTC
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
Re: Pipeline support - update with right link
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Feb 20, 2009 at 5:10 AM, paksegu <pa...@yahoo.com> 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.klimetschek@day.com
Re: Pipeline support
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> 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
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Feb 10, 2009 at 2:52 PM, Felix Meschberger <fm...@gmail.com> 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.klimetschek@day.com
Re: Pipeline support
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Carsten Ziegeler schrieb:
> Alexander Klimetschek wrote:
>> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger <fm...@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
Re: Pipeline support
Posted by paksegu <pa...@yahoo.com>.
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
paksegu@yahoo.com
http://www.noqmx.com/
https://serenade.dev.java.net/
--- On Tue, 2/10/09, Carsten Ziegeler <cz...@apache.org> wrote:
From: Carsten Ziegeler <cz...@apache.org>
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
<fm...@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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Pipeline support - update with right link
Posted by paksegu <pa...@yahoo.com>.
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
paksegu@yahoo.com
http://www.noqmx.com/
https://serenade.dev.java.net/
--- On Tue, 2/10/09, Carsten Ziegeler <cz...@apache.org> wrote:
From: Carsten Ziegeler <cz...@apache.org>
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
<fm...@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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Pipeline support
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote:
> On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger <fm...@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.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Pipeline support
Posted by Alexander Klimetschek <ak...@day.com>.
On Tue, Feb 10, 2009 at 12:13 PM, Felix Meschberger <fm...@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.
Just my 2 cents...
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Pipeline support
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> 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
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Tue, Mar 10, 2009 at 10:43 AM, Juan José Vázquez Delgado
<ju...@gmail.com> 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
Re: Pipeline support
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
>> ...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
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Juanjo,
On Tue, Mar 10, 2009 at 9:47 AM, Juan José Vázquez Delgado
<ju...@gmail.com> 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
Pipeline support
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
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:
<p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
<p:xslt>
<p:input port="stylesheet">
<p:document href="/xpl-sample/xsl/test-content.xslt"/>
</p:input>
</p:xslt>
<p:xslt>
<p:input port="stylesheet">
<p:document href="/xpl-sample/xsl/test-html.xslt"/>
</p:input>
</p:xslt>
</p:pipeline>
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
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
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:
<p:pipeline xmlns:p="http://www.w3.org/ns/xproc">
<p:xslt>
<p:input port="stylesheet">
<p:document
href="http://localhost:8888/xpl-sample/xsl/test-content.xslt"/>
</p:input>
</p:xslt>
</p:pipeline>
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
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
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
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
>> 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
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
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
Posted by Felix Meschberger <fm...@gmail.com>.
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
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> 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
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org