map:redirecto-to after map:transform/map:generate?
Hi,
I have a pipline that generates a file in the filesystem using a generator
and a transformation. The output is empty but I want to present in the
same request one of the generated files (index.html).
I tried to use
map:generate src=.../
map:transform type=xslt src=.../
map:redirect-to uri=chunk_{1}/
and have another map:match for chunk_* that reads index.html.
The problem is that obviously that pipeline is not executed at all but the
redirection happens immediately? Why it is after other things in the
pipeline!
Also it is not possible to use map:read/ or map:generate/ after a
transformation.
I tried also to use a XSL that produces input to xinclude but xinclude
can't wpork with cocoon:// URLs but needs a absolute path in the
base-Attribute.
So this also doesn't work.
So how can one read a file from the filesystem after a transformation?
And why does the redirect not work?
BTW, I'm using Cocoon 2.0.4
Thanks, Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
Peter Klotz wrote: So how can one read a file from the filesystem after a transformation? You can write a transformer / serializer that reads a file and generates the appropriate SAX events. I don't know if such a component already exists. And why does the redirect not work? There are some threads in the lists about this issue. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
Andreas Hartmann wrote: Peter Klotz wrote: So how can one read a file from the filesystem after a transformation? You can write a transformer / serializer that reads a file and generates the appropriate SAX events. I don't know if such a component already exists. Maybe you could use a stylesheet and the document function: xsl:param name=source/ xsl:template match=/ xsl:copy-of select=document($source)/*/ /xsl:template I think that should work. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
At 10:00 AM 6/3/2003, you wrote:
...
map:generate src=.../
map:transform type=xslt src=.../
map:redirect-to uri=chunk_{1}/
map:redirect-to issues a client side redirect. under what
circumstances would you want to do that along with an pipeline
content? are you looking for something like map:call? or
map:aggregate?
Also it is not possible to use map:read/ or map:generate/ after a
transformation.
Right, this is on purpose. If you need this, you should either use
map:aggregate or xinclude or cinclude.
I tried also to use a XSL that produces input to xinclude but xinclude
can't wpork with cocoon:// URLs but needs a absolute path in the
base-Attribute.
So this also doesn't work.
Try cinclude.
Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
At 10:31 AM 6/3/2003, you wrote: Andreas Hartmann wrote: Peter Klotz wrote: So how can one read a file from the filesystem after a transformation? You can write a transformer / serializer that reads a file and generates the appropriate SAX events. I don't know if such a component already exists. Maybe you could use a stylesheet and the document function: xsl:param name=source/ xsl:template match=/ xsl:copy-of select=document($source)/*/ /xsl:template I think that should work. It may, but I'd not recommend it. Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
Geoff Howard wrote: [...] xsl:template match=/ xsl:copy-of select=document($source)/*/ /xsl:template I think that should work. It may, but I'd not recommend it. Agreed. I should have mentioned this :) Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
--- Geoff Howard [EMAIL PROTECTED] wrote:
At 10:00 AM 6/3/2003, you wrote:
...
map:generate src=.../
map:transform type=xslt src=.../
map:redirect-to uri=chunk_{1}/
map:redirect-to issues a client side redirect.
under what
circumstances would you want to do that along with
an pipeline
content? are you looking for something like
map:call? or
map:aggregate?
Interesting, what is map:call? In my example, I need
to do the following:
1. submit a form
2. perform transformations
3. write to a file (SourceWritingTransformer)
4. display a page (other than the page with the
form)with updated content
Can I use map:call for that?
Also it is not possible to use map:read/ or
map:generate/ after a
transformation.
Right, this is on purpose. If you need this, you
should either use
map:aggregate or xinclude or cinclude.
I tried also to use a XSL that produces input to
xinclude but xinclude
can't wpork with cocoon:// URLs but needs a
absolute path in the
base-Attribute.
So this also doesn't work.
Try cinclude.
Geoff
-
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: map:redirecto-to after map:transform/map:generate?
map:call transfers to a pipeline fragment defined in
map:resources, but I don't think it will help you
specifically now that I see what you are trying to
do.
How about using an xslt transform after the
SourceWritingTransformer with something that
completely replaces all nodes with a cinclude?
eg,
xsl:template match=/
cinclude.../
/xsl:template
so you'd do
...
map:transform type=write-source/
map:transform src=that.xsl/
map:transform type=cinclude/
...
I don't like that very much and I'd love to hear a
more graceful solution from other users of the SWTransformer.
HTH,
Geoff
At 12:04 PM 6/3/2003, you wrote:
--- Geoff Howard [EMAIL PROTECTED] wrote:
At 10:00 AM 6/3/2003, you wrote:
...
map:generate src=.../
map:transform type=xslt src=.../
map:redirect-to uri=chunk_{1}/
map:redirect-to issues a client side redirect.
under what
circumstances would you want to do that along with
an pipeline
content? are you looking for something like
map:call? or
map:aggregate?
Interesting, what is map:call? In my example, I need
to do the following:
1. submit a form
2. perform transformations
3. write to a file (SourceWritingTransformer)
4. display a page (other than the page with the
form)with updated content
Can I use map:call for that?
Also it is not possible to use map:read/ or
map:generate/ after a
transformation.
Right, this is on purpose. If you need this, you
should either use
map:aggregate or xinclude or cinclude.
I tried also to use a XSL that produces input to
xinclude but xinclude
can't wpork with cocoon:// URLs but needs a
absolute path in the
base-Attribute.
So this also doesn't work.
Try cinclude.
Geoff
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
map:call transfers to a pipeline fragment defined in map:resources, but I don't think it will help you specifically now that I see what you are trying to do. map:call does not work the same way as map:redirect-to does not work because the steps before are not executed. Both must be the first and only statements in a map:match. How about using an xslt transform after the SourceWritingTransformer with something that completely replaces all nodes with a cinclude? eg, xsl:template match=/ cinclude.../ /xsl:template so you'd do ... map:transform type=write-source/ map:transform src=that.xsl/ map:transform type=cinclude/ ... I know both xinclude (and cinclude) as well as xsl:document() should work, the problem is that the file to include is a relative URL to the Cocoon-context path. Something like work/test/index.html. When using document() it expects it to be somehow in the same dir as the stylesheet. With xinclude one has to set the xml:base base URL otherwise it cannot resolve a relatie URL. The question what is the base URL?? /cocoon/app or cocoon://app or context:/ or http://hardcodedsvr/cocoon/app? I'd like xinclude much more than document(). cinclude I don't know very well. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
map:call does not work the same way as map:redirect-to does not work because the steps before are not executed. Both must be the first and only statements in a map:match. Hello Peter, fortunately the above is not true ;-) map:call resource=resourcename/ is a sitemap internal redirect for reusing pipeline fragments and so you can do first steps of a pipeline on another place than the resource. See also map:resource/. Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
At 01:03 PM 6/3/2003, you wrote: so you'd do ... map:transform type=write-source/ map:transform src=that.xsl/ map:transform type=cinclude/ ... I know both xinclude (and cinclude) as well as xsl:document() should work, the problem is that the file to include is a relative URL to the Cocoon-context path. Something like work/test/index.html. When using document() it expects it to be somehow in the same dir as the stylesheet. With xinclude one has to set the xml:base base URL otherwise it cannot resolve a relatie URL. The question what is the base URL?? /cocoon/app or cocoon://app or context:/ or http://hardcodedsvr/cocoon/app? I'd like xinclude much more than document(). cinclude I don't know very well. what about cocoon:/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
--- Geoff Howard [EMAIL PROTECTED] wrote: At 01:03 PM 6/3/2003, you wrote: so you'd do ... map:transform type=write-source/ map:transform src=that.xsl/ map:transform type=cinclude/ ... I know both xinclude (and cinclude) as well as xsl:document() should work, the problem is that the file to include is a relative URL to the Cocoon-context path. Something like work/test/index.html. When using document() it expects it to be somehow in the same dir as the stylesheet. With xinclude one has to set the xml:base base URL otherwise it cannot resolve a relatie URL. The question what is the base URL?? /cocoon/app or cocoon://app or context:/ or http://hardcodedsvr/cocoon/app? I'd like xinclude much more than document(). cinclude I don't know very well. what about cocoon:/ That's exactly my issue. The idea is to re-direct to a page, so including a file won't help: there is no file, instead there is a pipeline which generates the page. - 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: map:redirecto-to after map:transform/map:generate?
Ok, how about sending them a page with a meta refresh tag? I think an elegant solution exists with flow in 2.1, but couldn't help you get there at this stage. Geoff -Original Message- From: Alex Romayev [mailto:[EMAIL PROTECTED] --- Geoff Howard [EMAIL PROTECTED] wrote: At 01:03 PM 6/3/2003, you wrote: so you'd do ... map:transform type=write-source/ map:transform src=that.xsl/ map:transform type=cinclude/ ... what about cocoon:/ That's exactly my issue. The idea is to re-direct to a page, so including a file won't help: there is no file, instead there is a pipeline which generates the page. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
Hi Joerg,
map:call does not work the same way as map:redirect-to does not work
because the steps before are not executed. Both must be the first and
only
statements in a map:match.
[...]
fortunately the above is not true ;-)
map:call resource=resourcename/ is a sitemap internal redirect for
reusing pipeline fragments and so you can do first steps of a pipeline on
another place than the resource.
See also map:resource/.
I hear you saying this but when I try this
map:resources
map:resource name=chunk
map:read src=work/{service}/index.html mime-type=text/html/
/map:resource
/map:resources
and have a pipeline
map:pipeline
...
map:transform type=xslt .../
map:call resource=chunk
map:parameter name=service value={1}/
/map:call
/map:pipeline
It shouldn't be a problem being inside a selector? In the generation phase
of the pipline I get log records so I can see if the pipeline is really
executed completely.
And thus I can really see that immediately the resource is called and the
generation and transformation is definitely not executed!
Could it be that the behaviour changed after Cocoon 2.0.4 that I'm using?
The problem seems to be that the called resource is treated as if the
content is part of the calling pipeline. That means that I cannot use a
generator or read after a transformer. I tried exchanging the above read
with a map:generate/ and map:serialize/ and got a error that the
generator is already set in the pipeline.
I think this restriction is bad in this case. The transformer does not
create any output (docbook chunked HTML generation into files), therefore
it would not be a problem to have a generator afterwards. And a called
resource should behave like a sub-pipeline which it definitely does not at
the moment. Instead it behaves like a macro.
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: map:redirecto-to after map:transform/map:generate?
Hello Peter,
Peter Klotz wrote:
map:call resource=resourcename/ is a sitemap internal redirect for
reusing pipeline fragments and so you can do first steps of a pipeline on
another place than the resource.
See also map:resource/.
I hear you saying this but when I try this
map:resources
map:resource name=chunk
map:read src=work/{service}/index.html mime-type=text/html/
/map:resource
/map:resources
and have a pipeline
map:pipeline
...
map:transform type=xslt .../
map:call resource=chunk
map:parameter name=service value={1}/
/map:call
/map:pipeline
It shouldn't be a problem being inside a selector?
No, the selector is not the problem.
In the generation phase
of the pipline I get log records so I can see if the pipeline is really
executed completely.
And thus I can really see that immediately the resource is called and the
generation and transformation is definitely not executed!
Yes, of course ;-) see below.
Could it be that the behaviour changed after Cocoon 2.0.4 that I'm using?
No.
The problem seems to be that the called resource is treated as if the
content is part of the calling pipeline. That means that I cannot use a
generator or read after a transformer.
This is exactly the problem. You can only have one generator or one
map:read in your pipeline (independent of map:call/map:resource). And
because map:call/map:resource are only reusable pipeline fragments,
there is no difference having the stuff from map:resource at the end of
your pipeline where you have map:call. As I said it's only a sitemap
internal redirect.
I tried exchanging the above read
with a map:generate/ and map:serialize/ and got a error that the
generator is already set in the pipeline.
That's correct, the typical error message.
I think this restriction is bad in this case. The transformer does not
create any output (docbook chunked HTML generation into files), therefore
it would not be a problem to have a generator afterwards. And a called
resource should behave like a sub-pipeline which it definitely does not at
the moment. Instead it behaves like a macro.
It's a general restriction of the sitemap, it's part of the /sitemap
contract/. What you want to do is to chunk your DocBook file ad to
deliver the index.html of the chunk output? Difficult, I don't see any
solution for this. We always do the DocBook transformation offline and
deliver the resulting pages with a reader as you tried it.
Maybe extending the HTMLGenerator is an option for you. It could start
the transformation and afterwards return the HTML file. Otherwise you
must rethink the complete work flow.
Joerg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
