Re: aggregating duplicate parameters at sitemap level
Hi Jeroen,
Great! This works like a charm for pipelines only involving a file generator.
There is a further problem, however, for pipelines in which both an eXist
XQuery generator (pulling out an indexed XML resource from a database) and
further XSL stylesheets need access to the request parameters. When the
XQuery generator is called for in a map:part, it is impossible to pass
the request parameters:
map:aggregate element=root
!-- get XML representation of request --
map:part src=cocoon:/requestAsXML/
!-- get XQuery result --
map:part src=cocoon:/{1}.xq/
/map:aggregate
(with a separate match for the .xq part in the pipeline:)
map:match pattern=*.xq
map:generate src=xquery/simpleSearch.xq type=xquery
map:parameter name=use-request-parameters value=true/
/map:generate
map:serialize type=xml/
/map:match
When this part is pulled into the aggregation, the request parameters
can't be passed.
... I can probably bypass this aggregation step by mimicking it in my
XQuery scripts (since the duplicate parameter names are passed and handled
ok via use-request-parameters). But maybe there are better alternatives to
this ad-hoc approach?
Again, thanks very much for your kind and valuable advice!
Ron Van den Branden
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5
After a closer look at this thread: My earlier reply should not apply to your case.. Have you tried: xsl:apply-templates select=@* / xsl:apply-templates select=node() / I have noticed strange behaviours before and ran into similar trouble with Cocoon recently. I recommend putting latest Xalan in the endorsed folder of your Cocoon/webserver environment and making sure no other versions of Xalan are in the classpath. Java 1.5 is shipped with a certain version of Xalan, of which I recall it not being the most stable version that has passed. I also noticed that Saxon.jar can cause conflicts, but only when multiple copies of the jar are loaded (e.g. one in web-inf/lib/ and one in lib/endorsed/ of jetty). Are there other XSL parser in your classpath? HTH, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. Van: footh [mailto:[EMAIL PROTECTED] Verzonden: donderdag 8 februari 2007 23:27 Aan: users@cocoon.apache.org Onderwerp: Re: Unique XSL transform error that only occurs with Cocoon and Java 1.5 I had done that and should've mentioned it on my first message. The part that causes the error is the line: xsl:apply-templates select=@*|node() / In particulary, the select piece. It doesn't like the bar(|). If I get rid if it and only have either @* or node() then I don't get the error. This is valid XSL, as I said, the error only occurs when transforming with Cocoon and Java 1.5. --- Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 2/7/07, footh [EMAIL PROTECTED] wrote: ...Does anyone have any suggestions about where I would start looking to figure out what is going on?... If the exception gives no clue as to what's going wrong, I'd start commenting out parts of the transform to see exactly what causes it to fail. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ __ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. - 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]
Serialize to file?
I can't say I get all the pipeline concepts yet so excuse be if I'm missing something simple. Right now I only use the HTML serializer, but want to provide options in the app to use both the Text and HSSF serializers. Is is possible to configure the sitemap or serializer to 'save to file' and prompt the user with a SaveAs dialog? If not, is the standard approach to send output the the browser as normal and rely on the browser's menu options? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Serialize to file?
Hi Gary, i'll try to help you out. Gary Larsen wrote: I can't say I get all the pipeline concepts yet so excuse be if I'm missing something simple. Right now I only use the HTML serializer, but want to provide options in the app to use both the Text and HSSF serializers. Is is possible to configure the sitemap or serializer to 'save to file' and prompt the user with a SaveAs dialog? Well this is more or less a browser issue. Most browsers second-guess the server directives and do what they think is best. The browsers look at the file extension and try to guess the incoming content. I don't think there is a 100% reliable way of manipulating the browser to popup the 'save as' dialog. At OnJava I found an page recently with a solution [1]. You could try to set the content-type of the serializer to a type which is not recognized by the browser. For instance: application/x-download or application/x-unknown Next to that you can use an sitemap action or something equivalent to send an header to the browser: (Content-Disposition, attachment; filename=myfile.extension) If not, is the standard approach to send output the the browser as normal and rely on the browser's menu options? Yes you can do that. Thanks, Gary Your welcome! Regards, Jeroen Reijn [1] http://www.onjava.com/pub/a/onjava/excerpt/jebp_3/index3.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Serialize to file?
Hi Jeroen, Thanks for your advice and pointers. I'll give these a try. Gary You could try to set the content-type of the serializer to a type which is not recognized by the browser. For instance: application/x-download or application/x-unknown Next to that you can use an sitemap action or something equivalent to send an header to the browser: (Content-Disposition, attachment; filename=myfile.extension) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Best practice (was: How can i acces to Class from a Class name?)
Leszek Gawron wrote: still I advise you not to put business logic into flowscript. Did that once for medium sized project 3 years ago - now I have to support it and regret my decision a lot. Is there a sample in cocoon 2.1 which separates the various aspects (business logic, presentation, persistence / data storage / legacy database access) the way you would, or otherwise is widely recognized as best practice? Tobia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5
Geert, thanks for the replies. I tried all your recommended changes and nothing worked. I had xalan 2.7.0 in both the lib/endorsed dir of my web container (using Tomcat) and the lib directory of my web application. I tried various combinations (in one dir, not the other, etc.) and nothing worked - still the same transformer error. I also tried your stylesheet change and that had no effect. I still receive the same errors. The baffling thing is I ran this template through the xalan stylesheet command line utility under Java 1.5 and it transformed fine. Also, if I switch my web app environment to Java 1.4 it transforms fine. I have just run out of options to debug this thing. I have no idea where to start. Do you by any chance have a similar environment set up where you could test the template to see if you get the same error? Regards, JF --- Geert Josten [EMAIL PROTECTED] wrote: After a closer look at this thread: My earlier reply should not apply to your case.. Have you tried: xsl:apply-templates select=@* / xsl:apply-templates select=node() / I have noticed strange behaviours before and ran into similar trouble with Cocoon recently. I recommend putting latest Xalan in the endorsed folder of your Cocoon/webserver environment and making sure no other versions of Xalan are in the classpath. Java 1.5 is shipped with a certain version of Xalan, of which I recall it not being the most stable version that has passed. I also noticed that Saxon.jar can cause conflicts, but only when multiple copies of the jar are loaded (e.g. one in web-inf/lib/ and one in lib/endorsed/ of jetty). Are there other XSL parser in your classpath? HTH, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. Van: footh [mailto:[EMAIL PROTECTED] Verzonden: donderdag 8 februari 2007 23:27 Aan: users@cocoon.apache.org Onderwerp: Re: Unique XSL transform error that only occurs with Cocoon and Java 1.5 I had done that and should've mentioned it on my first message. The part that causes the error is the line: xsl:apply-templates select=@*|node() / In particulary, the select piece. It doesn't like the bar(|). If I get rid if it and only have either @* or node() then I don't get the error. This is valid XSL, as I said, the error only occurs when transforming with Cocoon and Java 1.5. --- Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 2/7/07, footh [EMAIL PROTECTED] wrote: ...Does anyone have any suggestions about where I would start looking to figure out what is going on?... If the exception gives no clue as to what's going wrong, I'd start commenting out parts of the transform to see exactly what causes it to fail. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ __ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. - 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] Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice (was: How can i acces to Class from a Class name?)
Is the Cocoon Bricks sample not still around somewhere? That was created for this very purpose and covered from database upto forms. Kind regards, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. Van: Tobia [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 9 februari 2007 19:10 Aan: users@cocoon.apache.org Onderwerp: Best practice (was: How can i acces to Class from a Class name?) Leszek Gawron wrote: still I advise you not to put business logic into flowscript. Did that once for medium sized project 3 years ago - now I have to support it and regret my decision a lot. Is there a sample in cocoon 2.1 which separates the various aspects (business logic, presentation, persistence / data storage / legacy database access) the way you would, or otherwise is widely recognized as best practice? Tobia - 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: aggregating duplicate parameters at sitemap level
[EMAIL PROTECTED] wrote:
When the XQuery generator is called for in a map:part, it is
impossible to pass the request parameters:
map:aggregate element=root
!-- get XML representation of request --
map:part src=cocoon:/requestAsXML/
!-- get XQuery result --
map:part src=cocoon:/{1}.xq/
/map:aggregate
(with a separate match for the .xq part in the pipeline:)
map:match pattern=*.xq
map:generate src=xquery/simpleSearch.xq type=xquery
map:parameter name=use-request-parameters value=true/
/map:generate
map:serialize type=xml/
/map:match
I would store the request *parameters* you need in request *attributes*.
Pipeline, part 1:
act type=set-request-attr
parameter name=foo value={request-param:foo}/
parameter name=bar value={request-param:bar}/
map:aggregate element=root
!-- get XML representation of request --
map:part src=cocoon:/requestAsXML/
!-- get XQuery result --
map:part src=cocoon:/{../1}.xq/
/map:aggregate
/act
(Don't forget that {1} becomes {../1}.)
Part 2:
map:match pattern=*.xq
map:generate src=xquery/simpleSearch.xq type=xquery
map:parameter name=foo value={request-attr:foo}/
map:parameter name=bar value={request-attr:bar}/
/map:generate
map:serialize type=xml/
/map:match
This has the added benefit of avoiding use-request-parameters, which is
generally frowned upon for various reasons.
You will need this component:
action name=set-request-attr
src=org.apache.cocoon.acting.PropagatorAction
output-module name=request-attr/
store-empty-parametersfalse/store-empty-parameters
/action
(store-empty-parameters is a matter of preference.)
And this change in cocoon.xconf (adding an empty key-prefix option to
the request-attr *output* module):
output-modules
- component-instance ... name=request-attr/
+ component-instance ... name=request-attr
+ key-prefix/
+ /component-instance
...
/output-modules
Take it all with a grain of salt, I am not a Cocoon expert :-)
Tobia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5
Can you give me the following 1) minimal XSL stylesheets 2) minimal XML example 3) relevant sitemap fragment 4) Java build number (java -version) And any other relevant information. Can't promiss, but I will try to take a look. It is always good to be aware of bugs or common mistakes in XSL parsers and Java/Cocoon setups.. Kind regards, Geert -Oorspronkelijk bericht- Van: footh [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 9 februari 2007 19:28 Aan: users@cocoon.apache.org Onderwerp: RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5 Geert, thanks for the replies. I tried all your recommended changes and nothing worked. I had xalan 2.7.0 in both the lib/endorsed dir of my web container (using Tomcat) and the lib directory of my web application. I tried various combinations (in one dir, not the other, etc.) and nothing worked - still the same transformer error. I also tried your stylesheet change and that had no effect. I still receive the same errors. The baffling thing is I ran this template through the xalan stylesheet command line utility under Java 1.5 and it transformed fine. Also, if I switch my web app environment to Java 1.4 it transforms fine. I have just run out of options to debug this thing. I have no idea where to start. Do you by any chance have a similar environment set up where you could test the template to see if you get the same error? Regards, JF --- Geert Josten [EMAIL PROTECTED] wrote: After a closer look at this thread: My earlier reply should not apply to your case.. Have you tried: xsl:apply-templates select=@* / xsl:apply-templates select=node() / I have noticed strange behaviours before and ran into similar trouble with Cocoon recently. I recommend putting latest Xalan in the endorsed folder of your Cocoon/webserver environment and making sure no other versions of Xalan are in the classpath. Java 1.5 is shipped with a certain version of Xalan, of which I recall it not being the most stable version that has passed. I also noticed that Saxon.jar can cause conflicts, but only when multiple copies of the jar are loaded (e.g. one in web-inf/lib/ and one in lib/endorsed/ of jetty). Are there other XSL parser in your classpath? HTH, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. Van: footh [mailto:[EMAIL PROTECTED] Verzonden: donderdag 8 februari 2007 23:27 Aan: users@cocoon.apache.org Onderwerp: Re: Unique XSL transform error that only occurs with Cocoon and Java 1.5 I had done that and should've mentioned it on my first message. The part that causes the error is the line: xsl:apply-templates select=@*|node() / In particulary, the select piece. It doesn't like the bar(|). If I get rid if it and only have either @* or node() then I don't get the error. This is valid XSL, as I said, the error only occurs when transforming with Cocoon and Java 1.5. --- Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 2/7/07, footh [EMAIL PROTECTED] wrote: ...Does anyone have any suggestions about where I would start looking to figure out what is going on?... If the exception gives no clue as to what's going wrong, I'd start commenting out parts of the transform to see exactly what causes it to fail. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ __ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. - 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] __ __ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
RE: Serialize to file?
I typically use the following, though there are other solutions
possible:
map:match pattern=download-*-zip
map:generate src=cocoon:/generate-{1}-zip/
map:act type=set-header
map:parameter name=Content-Type
value=application/x-download/
map:parameter name=Content-Disposition value=attachment ;
filename={1}.zip/
map:serialize type=zip/
/map:act
/map:match
Other serializers are possible ofcourse.. :-)
HTH,
Geert
Drs. G.P.H. Josten
Consultant
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel.: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
www.daidalos.nl
KvK 27164984
De informatie - verzonden in of met dit emailbericht - is afkomstig van
Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit
bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit
bericht kunnen geen rechten worden ontleend.
Van: Gary Larsen [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 9 februari 2007 17:02
Aan: users@cocoon.apache.org
Onderwerp: RE: Serialize to file?
Hi Jeroen,
Thanks for your advice and pointers. I'll give these a try.
Gary
You could try to set the content-type of the serializer to a type
which is not recognized by the browser. For instance:
application/x-download or application/x-unknown
Next to that you can use an sitemap action or something
equivalent to
send an header to the browser:
(Content-Disposition, attachment; filename=myfile.extension)
-
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: Best practice (was: How can i acces to Class from a Class name?)
On 2/9/07, Geert Josten [EMAIL PROTECTED] wrote: Is the Cocoon Bricks sample not still around somewhere?... Yes, http://wiki.apache.org/cocoon/BricksCms is the place. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Serialize to file?
Thanks Geert. This helps me understand actions a bit more also!
Gary
map:match pattern=download-*-zip
map:generate src=cocoon:/generate-{1}-zip/
map:act type=set-header
map:parameter name=Content-Type
value=application/x-download/
map:parameter name=Content-Disposition
value=attachment ; filename={1}.zip/
map:serialize type=zip/
/map:act
/map:match
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5
Geert, I think I have solved the problem. When you asked me for the minimal example, I realized that I had never done that. I figured that my XSLs weren't too complicated so there was no need to reduce it to bare minimum. So, I created a very simple example, and it worked! I then started adding more and more until I figured out what was causing the error. Turns out, I was including a third-party XSL to do some stuff and there was this line at the top: xsl:output method=html omit-xml-declaration=yes indent=no/ Simply removing this line got rid of the error. Why it caused the exception at that particular part of the identity template, I don't know, but I'm glad the issue is resolved. Thanks for you help, JF --- Geert Josten [EMAIL PROTECTED] wrote: Can you give me the following 1) minimal XSL stylesheets 2) minimal XML example 3) relevant sitemap fragment 4) Java build number (java -version) And any other relevant information. Can't promiss, but I will try to take a look. It is always good to be aware of bugs or common mistakes in XSL parsers and Java/Cocoon setups.. Kind regards, Geert -Oorspronkelijk bericht- Van: footh [mailto:[EMAIL PROTECTED] Verzonden: vrijdag 9 februari 2007 19:28 Aan: users@cocoon.apache.org Onderwerp: RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5 Geert, thanks for the replies. I tried all your recommended changes and nothing worked. I had xalan 2.7.0 in both the lib/endorsed dir of my web container (using Tomcat) and the lib directory of my web application. I tried various combinations (in one dir, not the other, etc.) and nothing worked - still the same transformer error. I also tried your stylesheet change and that had no effect. I still receive the same errors. The baffling thing is I ran this template through the xalan stylesheet command line utility under Java 1.5 and it transformed fine. Also, if I switch my web app environment to Java 1.4 it transforms fine. I have just run out of options to debug this thing. I have no idea where to start. Do you by any chance have a similar environment set up where you could test the template to see if you get the same error? Regards, JF --- Geert Josten [EMAIL PROTECTED] wrote: After a closer look at this thread: My earlier reply should not apply to your case.. Have you tried: xsl:apply-templates select=@* / xsl:apply-templates select=node() / I have noticed strange behaviours before and ran into similar trouble with Cocoon recently. I recommend putting latest Xalan in the endorsed folder of your Cocoon/webserver environment and making sure no other versions of Xalan are in the classpath. Java 1.5 is shipped with a certain version of Xalan, of which I recall it not being the most stable version that has passed. I also noticed that Saxon.jar can cause conflicts, but only when multiple copies of the jar are loaded (e.g. one in web-inf/lib/ and one in lib/endorsed/ of jetty). Are there other XSL parser in your classpath? HTH, Geert Drs. G.P.H. Josten Consultant Daidalos BV Source of Innovation Hoekeindsehof 1-4 2665 JZ Bleiswijk Tel.: +31 (0) 10 850 1200 Fax: +31 (0) 10 850 1199 www.daidalos.nl KvK 27164984 De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend. Van: footh [mailto:[EMAIL PROTECTED] Verzonden: donderdag 8 februari 2007 23:27 Aan: users@cocoon.apache.org Onderwerp: Re: Unique XSL transform error that only occurs with Cocoon and Java 1.5 I had done that and should've mentioned it on my first message. The part that causes the error is the line: xsl:apply-templates select=@*|node() / In particulary, the select piece. It doesn't like the bar(|). If I get rid if it and only have either @* or node() then I don't get the error. This is valid XSL, as I said, the error only occurs when transforming with Cocoon and Java 1.5. --- Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 2/7/07, footh [EMAIL PROTECTED] wrote: ...Does anyone have any suggestions about where I would start looking to figure out what is going on?... If the exception gives no clue as to what's going wrong, I'd start commenting out parts of the transform to see exactly what causes it to fail. -Bertrand -
