aggregating duplicate parameters at sitemap level
Hi,
In my application, I have some HTML forms containing lists of checkbox
inputs and multiple select boxes. This results in request URIs featuring
duplicate parameter names:
e.g.:
http://localhost:/myapp/processform.htm?par1=val1par1=val2par1=val3
If I pass these to my XSLT transformation using map:parameter
name=use-request-parameters value=true/, only the first value (viz.
val1) ends up in my XSLT. This is a short sitemap.xmap snippet:
map:match pattern=processform.htm
map:generate src=xml/{1}.xml/
map:transform src=stylesheets/xml2htm/{1}.xsl
map:parameter name=use-request-parameters value=true/
/map:transform
map:serialize type=xhtml/
/map:match
So far, I worked around this with client-side Javascript that would
aggregate those values for the duplicate parameters into one string, so
that only 1 par1 parameter is passed through:
e.g.: http://localhost:/myapp/processform.htm?par1=val1%20val2%20val3
In revising my app (and bringing it closer to unobtrusive JS practice),
however, I would like to free that vital part of its fuctionality (form
submission) from this client-side Javascript dependency.
My question is: is there a way of aggregating duplicate parameters into
one parameter at sitemap level? The scarce posts I came across on this
list suggest that it *can* be done (e.g.
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=113474098814411w=2),
but not exactly how... At least, I can't see a solution with my current
cocoon knowledge (not much beyond simple pipeline concepts, ie. no
flowscript, actions, XSP...).
I recognize this is not strictly a Cocoon problem (and apologize for
off-topicality), but hope there may be a Cocoon solution?
Thanks for any reaction!
Ron Van den Branden
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
using xslt-processing-instructions to trigger transformers
Hi there, does anybody knows if it is possible to use xslt-processing-instructions to call an transformer? The basic idea is that xml-/xsp-files know if they should be transformed using an cinclude transformer rather than writing a map:match in the sitemap for each of them. I tried allready ?cocoon-process type=cinclude? but that didn't work. Thanks and greetings Janne K. Olesen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using xslt-processing-instructions to trigger transformers
On 2/8/07, Janne K. Olesen [EMAIL PROTECTED] wrote: ...The basic idea is that xml-/xsp-files know if they should be transformed using an cinclude transformer rather than writing a map:match in the sitemap for each of them. I tried allready ?cocoon-process type=cinclude?... This is more or less how things worked in Cocoon 1.x...but for many reasons, the project moved to using sitemaps exclusively, and this is not supported anymore. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: aggregating duplicate parameters at sitemap level
Hi Ron,
since you want to keep it as simple as possible, you could also take a
look at the RequestGenerator [1]. You can then use your XSL to process
the multiple results.
In that case the only thing you need to do in your sitemap is change
your generate part to an aggregate and you will probably have to change
your xslt a bit and that would be it.
Just as a side note: I always discourage use-request-parameters, since
it can give you problems when using caching pipelines.
Kind regards,
Jeroen Reijn
[1]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/generation/RequestGenerator.html
Ron Van den Branden wrote:
Hi,
In my application, I have some HTML forms containing lists of checkbox
inputs and multiple select boxes. This results in request URIs featuring
duplicate parameter names:
e.g.:
http://localhost:/myapp/processform.htm?par1=val1par1=val2par1=val3
If I pass these to my XSLT transformation using map:parameter
name=use-request-parameters value=true/, only the first value (viz.
val1) ends up in my XSLT. This is a short sitemap.xmap snippet:
map:match pattern=processform.htm
map:generate src=xml/{1}.xml/
map:transform src=stylesheets/xml2htm/{1}.xsl
map:parameter name=use-request-parameters value=true/
/map:transform
map:serialize type=xhtml/
/map:match
So far, I worked around this with client-side Javascript that would
aggregate those values for the duplicate parameters into one string, so
that only 1 par1 parameter is passed through:
e.g.: http://localhost:/myapp/processform.htm?par1=val1%20val2%20val3
In revising my app (and bringing it closer to unobtrusive JS practice),
however, I would like to free that vital part of its fuctionality (form
submission) from this client-side Javascript dependency.
My question is: is there a way of aggregating duplicate parameters into
one parameter at sitemap level? The scarce posts I came across on this
list suggest that it *can* be done (e.g.
http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=113474098814411w=2),
but not exactly how... At least, I can't see a solution with my current
cocoon knowledge (not much beyond simple pipeline concepts, ie. no
flowscript, actions, XSP...).
I recognize this is not strictly a Cocoon problem (and apologize for
off-topicality), but hope there may be a Cocoon solution?
Thanks for any reaction!
Ron Van den Branden
-
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
Hi Ron,
Ron Van den Branden wrote:
Hi Jeroen,
Thanks a lot for this quick and helpful hint: I now manage to get an XML
representation of the request with the RequestGenerator. That's
excellent for XSL processing, but... I still don't see clearly how I can
integrate this in the pipeline (sorry - I take full account of my
ignorance).
No problem. I had to learn all of this myself too! :-) Well since the
all request parameters are in the generator, you will not have to pass
them to the transformer, since you already have them.
Jeroen Reijn schreef:
In that case the only thing you need to do in your sitemap is change
your generate part to an aggregate and you will probably have to
change your xslt a bit and that would be it.
Do I understand you correctly by thinking that you'd aggregate both the
XML request representation (via RequestGenerator) and the requested XML
source (via another pipeline) into an XML structure for further
processing? Something like:
map:match pattern=processform.htm
map:aggregate
!-- get XML representation of request --
map:part src=???/
!-- get XML source --
map:part src=???/
/map:aggregate
map:transform src=stylesheets/xml2htm/{1}.xsl
map:parameter name=use-request-parameters value=true/
/map:transform
map:serialize type=xhtml/
/map:match
Then the question marks are unclear to me...
You are correct with the above. The aggregate should in your case look like:
map:aggregate element=root
!-- get XML representation of request --
map:part src=cocoon:/requestAsXML/
!-- get XML source --
map:part src=xml/{1}.xml/
/map:aggregate
As you might have noticed the first part calls another pipeline which
generates the request. That should be:
map:match pattern=requestAsXML
map:generate type=request/
map:serialize type=xml/
/map:match
Now you will have to change your xslt to handle the extra wrapping
element and that should be it.
Just as a side note: I always discourage use-request-parameters, since
it can give you problems when using caching pipelines.
What alternative do you suggest?
Well it depends on what you want to do within your pipeline, but I
always declare my request parameters separately. Using the
use-request-parameters parameter will make all your request parameters
end up in your cachekey (if your pipeline is set to caching). So if
let's say some crawler runs by your website and the crawler uses a time
stamp as a request parameter, all these request will get a seperate
cachekey. It will enlarge your cache enormously.
Thank you very much,
Your welcome.
Jeroen Reijn
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Store Janitor configuration
I'm having problems configuring the memory allocation for the Store Janitor. if we have something like: store-janitor logger=core.store.janitor parameter name=freememory value=104857600/ parameter name=heapsize value=515396075/ !-- ~ 96% of 512 MB -- store-janitor logger=core.store.janitor And the JVM is: -Xms512m -Xmx512m Does this mean that that the JVM will always have 104857600 available? What does the JVM with that amount of memory? I've put cocoon in DEBUG mode and I'm seeing too many messages Memory is low! which is causing elements to be removed from cache. How can improve this? 1. Decrease the freememory value? 2. Decrease the heapsize value? 3. Should the value of freememory + heapsize be smaller that the JVM value? What's the freememory used by anyway? I know that this is for the JVM, but should this be changed according to the amount of memory that cocoon needs to run? Please let me know what you think of Many Thanks
Re: parameters in chained transforms
Tobia wrote: By the way, can I access Cocoon's objects (request, session...) through an xslt/xpath extension? That would be useful. That would not be a good idea - you break pipeline caching. You are probably better off using input modules to pass those values via sitemap parameters -- Leszek GawronCTO at MobileBox Ltd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Preventing ambiguous imports in flowscript
Niels van Kampenhout wrote: Hi, Niels van Kampenhout wrote: Lionel Barth wrote: I had the same problem updating from 2.1.7 to 2.1.10. I found a solution in http://wiki.apache.org/cocoon/JavascriptForJavaProgrammers : *Note:* Be sure to make importPackage(...) the first code line in your script, or you may get an Ambiguous import error on the second and following runs of your script when attempting to reference an imported class. Thanks Lionel, I also found this Wiki page and tried that, but it doesn't really help. The strange thing is this: the application uses an ajax-like javascript framework to load pages in the background and display them in the browser without page reloading. If I request those different pages separately in the browser, everything works fine, and even more weird, after that the complete application also works fine without the ambiguous import errors. I only get them when I load the complete application directly after starting Cocoon. I think I worked around the problem by avoiding importPackage() altogether and importing only the actual classes with importClass() instead. this is a Rhino bug - use lastest snapshot build, it will work. see the bug I reported: https://bugzilla.mozilla.org/show_bug.cgi?id=350580 -- Leszek GawronCTO at MobileBox Ltd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: manager.lookup fails without exception
Tilman Rassy wrote: Hello, we have the following problem: in a custom generator, we have dbHelper = (DbHelper)this.manager.lookup(DbHelper.ROLE); this fails for some reason, but no exception is thrown. The server simply replies with response code 500. If I place log messages before and after the line above, I see the first message in the log files, but not the second. No error messages occur in the logs. It is impossible that servlet container goes HTTP 500 without any exception. You are probably missing one. You should check both container logs and cocoon logs. -- Leszek GawronCTO at MobileBox Ltd. - 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
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]
RE: Unique XSL transform error that only occurs with Cocoon and Java 1.5
The expression is not necessarily correct actually, but that depends on context and content.. :-) For instance: xsl:copy newelem / xsl:apply-templates select=@* / /xsl:copy is not valid, but is likely to cause only errors when the current element has attributes.. 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: 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]
jx generator in 2.1.10
I had previously mentioned in passing that when I tested my site with
2.1.10
a bunch of things broke which were working in 2.1.9, but I hadn't had
time to
figure out specifically what piece was broken.
We upgraded our production server to 2.1.10 and someone else looked
into this bug:
parameters were no longer being passed to the jx generator.
Swapping the names in the main sitemap so that the generator formerly
named jx
is now oldjx, and the generator named newjx is now jx seems to
fix this problem.
Looking back, I see this note in the release notes, but I'm not sure
how to interpret
what it's saying in terms of whether it indicates a different usage
in jx generator templates
( Can someone explain parameters object vs properties object ? )
*) The predefined variables parameters and cocoon.parameters
now both point to the parameters object in JXTemplateGenerator and
the template block. (cocoon.parameters did point to a properties
object). [CZ]
But my sitemap passed parameters to the jx generator:
map:generate src=scripts/eadframe.jx type=jx
map:parameter name=docpath value=published/{1}/{2} /
map:parameter name=instdir value={1} /
map:parameter name=document value={2} /
/map:generate
And the template substituted: ${cocoon.parameters.document}
-- Steve Majewski / UVA Alderman Library
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
