RE: pipeline dependencies
Create a simple selector to check if the file exists, and if it doesn't call pipeline A. David -Mensaje original- De: Ali Mesbah [mailto:[EMAIL PROTECTED] Enviado el: jueves, 19 de junio de 2003 14:10 Para: [EMAIL PROTECTED] Asunto: pipeline dependencies Hi, Is it possible to define pipeline dependencies in the sitemap? Imagine I have two pipelines A and B. Pipeline B has a SourceWritingTransformer and all it does is writing a generated document on the filesystem. Pipeline A has its own generator and transformer but it depends on the document written by B. So A denpends on B. In other words when A is called B has to be called first but the output of A sould be serialized to the browser (and not the output of B). Thanks, Ali -- -- Ali Mesbah, West Consulting B.V., www.west.nl, +31 15 2191600 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pipeline dependencies
As quoted from Upayavira [EMAIL PROTECTED]: Is it possible to define pipeline dependencies in the sitemap? Imagine I have two pipelines A and B. Pipeline B has a SourceWritingTransformer and all it does is writing a generated document on the filesystem. Pipeline A has its own generator and transformer but it depends on the document written by B. So A denpends on B. In other words when A is called B has to be called first but the output of A sould be serialized to the browser (and not the output of B). You could try just including pipeline B in with pipeline A using cocoon:, e.g. map:match pattern=B map:generate... map:transform type=SWT map:serialize type=xml/ /map:match map:match pattern=A map:aggregate element=foo map:part src=cocoon:/B/ map:part src=a-src.xml/ /map:aggregate map:transform... map:serialize... /map:match If you can get pipeline B to cache, then it will only write if the source of that pipeline has changed. Then, if necessary, you can ignore the aggregated output from pipeline B, but it is just there to enforce the dependency. All depends upon the caching of the SourceWritingTransformer. Thanks Upayavira. I think with the current implementation that is the only possible way of doing it. Although it's not efficient (you dont actually want to aggregate), it serves the purpose. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Ali Mesbah, West Consulting B.V., www.west.nl, +31 15 2191600 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pipeline dependencies
If you can get pipeline B to cache, then it will only write if the source of that pipeline has changed. Then, if necessary, you can ignore the aggregated output from pipeline B, but it is just there to enforce the dependency. All depends upon the caching of the SourceWritingTransformer. Thanks Upayavira. I think with the current implementation that is the only possible way of doing it. Although it's not efficient (you dont actually want to aggregate), it serves the purpose. Another way you can do it is read your original content from disc, then transform it into something like: xml source:write contentBlah/content /source:write contentBlah/content /xml This way you repeat your content twice, once to go into the SWT, and once to go on to the output. Your following transformer then just strips out any nodes in the SWT namespace. Make sense? Can you explain a little more _why_ you want to be writing to disk? That'll help me understand how best you can achieve your requirements. Regards, Upayavira map:match ... map:generate src=original source map:transform src=make_ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pipeline dependencies
As quoted from Upayavira [EMAIL PROTECTED]:
Another way you can do it is read your original content from disc, then transform it
into something like:
xml
source:write
contentBlah/content
/source:write
contentBlah/content
/xml
This way you repeat your content twice, once to go into the SWT, and once to go on
to the output. Your following transformer then just strips out any nodes in the SWT
namespace.
Make sense?
Can you explain a little more _why_ you want to be writing to disk? That'll help me
understand how best you can achieve your requirements.
The thing is I generate a stylesheet in B which is used in A (and in other
pipelines):
match pattern=B
map:generate src=resources/{filename}.xml/
map:transform src=styles/Meta_output.xsl/
map:serialize type=xml/
/map:match
Note that the output of B is a stylesheet (say output.xsl).
Then the first thing that comes to mind is using the Cocoon protocol to read
this output.xsl as the src of the transformer in A:
match pattern=A
map:generate src=resources/bla.xml/
map:transform src=cocoon:/B/
map:serialize type=html/
/map:match
But unfortunately this does not work. (I have posted messages on this matter a
few days ago). The output of A is not what it should be at all.
So I thought a workaround is to write the output.xsl to file and then read it in
A. But then I had the issue of dependencies
I hope i have been clear enough. By the way have you ever tried to use cocoon:/
as the src of a Transformer?
Thanks,
Ali
Regards, Upayavira
map:match ...
map:generate src=original source
map:transform src=make_
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- Ali Mesbah, West Consulting B.V., www.west.nl, +31 15 2191600
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pipeline dependencies
The thing is I generate a stylesheet in B which is used in A (and in
other pipelines):
match pattern=B
map:generate src=resources/{filename}.xml/
map:transform src=styles/Meta_output.xsl/
map:serialize type=xml/
/map:match
Note that the output of B is a stylesheet (say output.xsl).
Then the first thing that comes to mind is using the Cocoon protocol
to read this output.xsl as the src of the transformer in A:
match pattern=A
map:generate src=resources/bla.xml/
map:transform src=cocoon:/B/
map:serialize type=html/
/map:match
But unfortunately this does not work. (I have posted messages on this
matter a few days ago). The output of A is not what it should be at
all.
So I thought a workaround is to write the output.xsl to file and then
read it in A. But then I had the issue of dependencies
I hope i have been clear enough. By the way have you ever tried to use
cocoon:/ as the src of a Transformer?
Ah. Much clearer now. No you shouldn't use the SWT to do this - you should be able
to rely upon Cocoon's caching to worry about that for you.
Yes, you can access stylesheets using the cocoon: protocol. No I haven't done it yet,
but I will need to do so soon.
So, when you say you tried it and it doesn't work, what doesn't work? What happens?
Also, what version of Cocoon are you using?
Regards, Upayavira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pipeline dependencies
As quoted from Upayavira [EMAIL PROTECTED]:
Ali,
Have you seen:
http://wiki.cocoondev.org/Wiki.jsp?page=MetaStylesheets
Maybe that'll help.
It works indeed. I see what I was doing wrong;
In my Meta_output at some places I had something like:
xsl:text disable-output-escaping=yes
lt;xsl:apply-templatesgt;
lt;xsl:with-param name=path select=$root/gt;
lt;/xsl:apply-templatesgt;
/xsl:text
This works if you save the output on filesystem and read it again but not using
it directly via Cocoon protocol. The trick is to create elements explicitely instead
of using xsl:text:
xsl:element name=xsl:apply-templates
xsl:element name=xsl:with-param
xsl:attribute name=namepath/xsl:attribute
xsl:attribute name=select
xsl:text$root/xsl:text
/xsl:attribute
/xsl:element
/xsl:element
Thanks Upayavira for helping out,
Ali
Regards, Upayavira
On 20 Jun 2003 at 11:16, Ali Mesbah wrote:
As quoted from Upayavira [EMAIL PROTECTED]:
Another way you can do it is read your original content from disc,
then transform it into something like:
xml
source:write
contentBlah/content
/source:write
contentBlah/content
/xml
This way you repeat your content twice, once to go into the SWT, and
once to go on to the output. Your following transformer then just
strips out any nodes in the SWT namespace.
Make sense?
Can you explain a little more _why_ you want to be writing to disk?
That'll help me understand how best you can achieve your
requirements.
The thing is I generate a stylesheet in B which is used in A (and in
other pipelines):
match pattern=B
map:generate src=resources/{filename}.xml/
map:transform src=styles/Meta_output.xsl/
map:serialize type=xml/
/map:match
Note that the output of B is a stylesheet (say output.xsl).
Then the first thing that comes to mind is using the Cocoon protocol
to read this output.xsl as the src of the transformer in A:
match pattern=A
map:generate src=resources/bla.xml/
map:transform src=cocoon:/B/
map:serialize type=html/
/map:match
But unfortunately this does not work. (I have posted messages on this
matter a few days ago). The output of A is not what it should be at
all.
So I thought a workaround is to write the output.xsl to file and then
read it in A. But then I had the issue of dependencies
I hope i have been clear enough. By the way have you ever tried to use
cocoon:/ as the src of a Transformer?
Thanks,
Ali
Regards, Upayavira
map:match ...
map:generate src=original source
map:transform src=make_
- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- Ali Mesbah, West Consulting B.V., www.west.nl, +31 15 2191600
-
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-- Ali Mesbah, West Consulting B.V., www.west.nl, +31 15 2191600
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pipeline dependencies
Is it possible to define pipeline dependencies in the sitemap? Imagine I have two pipelines A and B. Pipeline B has a SourceWritingTransformer and all it does is writing a generated document on the filesystem. Pipeline A has its own generator and transformer but it depends on the document written by B. So A denpends on B. In other words when A is called B has to be called first but the output of A sould be serialized to the browser (and not the output of B). You could try just including pipeline B in with pipeline A using cocoon:, e.g. map:match pattern=B map:generate... map:transform type=SWT map:serialize type=xml/ /map:match map:match pattern=A map:aggregate element=foo map:part src=cocoon:/B/ map:part src=a-src.xml/ /map:aggregate map:transform... map:serialize... /map:match If you can get pipeline B to cache, then it will only write if the source of that pipeline has changed. Then, if necessary, you can ignore the aggregated output from pipeline B, but it is just there to enforce the dependency. All depends upon the caching of the SourceWritingTransformer. I may well be off track here... Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pipeline dependencies
- Original Message - From: Nick Entin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 07, 2001 12:02 PM Subject: Pipeline dependencies Hello! Does anybody know is that possible to make one pipeline to be dependent on another? Like I have a 2 frames in result - left frame is processed by one pipeline and right - by another. I want to be sure that the 'left' pipeline is executed first, because it produces some data, used by the 'right' one. Another possible solution for me would be if a transformer could get as src result of a pipeline, like: map:match pattern=TRANSFORMER map:generate src=data/test.xml / map:transform src=data/markedxsl.xsl / map:serialize type=xml / /map:match map:match pattern=xxx map:generate src=data/test.xml / map:transform src=TRANSFORMER / map:serialize type=html / /map:match My attempts to make it running failed. Do I need additional things configured? AFAIK, this is not possible. Having the same problem, I did another thing; invoked only the first page and put a script at the end of it that loads the other document in the other frame. Nicola Ken Barozzi These are the days of miracle and wonder... ...so don't cry baby, don't cry [EMAIL PROTECTED] Paul Simon - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pipeline dependencies
It is possible. I'm using that in my site: map:pipeline map:match pattern=pd/mergedoc.html map:generate src=_thesource_/ map:transform src=cocoon:/rtf_merge_data/ map:serialize type=html/ /map:match /map:pipeline map:pipeline internal-only=true map:match pattern=rtf_merge_data map:generate type=serverpages src=pages/gen_merge_xsl.xsp/ map:serialize type=xml/ /map:match /map:pipeline DR At 12:22 PM 12/7/01 +0100, you wrote: - Original Message - From: Nick Entin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 07, 2001 12:02 PM Subject: Pipeline dependencies Hello! Does anybody know is that possible to make one pipeline to be dependent on another? Like I have a 2 frames in result - left frame is processed by one pipeline and right - by another. I want to be sure that the 'left' pipeline is executed first, because it produces some data, used by the 'right' one. Another possible solution for me would be if a transformer could get as src result of a pipeline, like: map:match pattern=TRANSFORMER map:generate src=data/test.xml / map:transform src=data/markedxsl.xsl / map:serialize type=xml / /map:match map:match pattern=xxx map:generate src=data/test.xml / map:transform src=TRANSFORMER / map:serialize type=html / /map:match My attempts to make it running failed. Do I need additional things configured? AFAIK, this is not possible. Having the same problem, I did another thing; invoked only the first page and put a script at the end of it that loads the other document in the other frame. Nicola Ken Barozzi These are the days of miracle and wonder... ...so don't cry baby, don't cry [EMAIL PROTECTED] Paul Simon - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faqs.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
