Calling function in root sitemap flow
Hi all, obviously I’m missing something: Could anyone please point me towards the proper method of calling a function in root sitemap flow (incl. passing parameters) from a sub-sitemap’s matcher ? Is this possible at all ? Thanks for any hint !! Best, Bardo
Re: Accessing application/json message body of POST request
Hi Warrell,
thanks for the input.
Though our problem actually isn't *processing* the JSON, but initially
getting it out of a POST request's application/json message body at all.
If the JSON is postet wwwform-urlencoded and comes with common
variable-value pairs, indeed a variety of options exists.
If, however, one cannot even destill the payload itself out of the
request, the largest variety of processing options is not of much help.
What I get is more something like this
POST /serviceendpoint/ HTTP/1.1
Host: mydomain.com
Authorization: MyAuthKeyHere
Accept-Encoding: gzip, deflate
Content-Type: application/json // this is the identified reason, why
Cocoon stops processing before the message body
Accept-Language: en-us
Accept: */*
Content-Length: 80
Connection: keep-alive
User-Agent: proprietaryUA
{jsonPayload:verylongpayloadcontentcangohereifyoulike}
Nonetheless, thanks for all of your suggestions; will get back to these
lateron for sure...
Best,
Bardo
On 16.03.14 23.00 Uhr, warrell harries wrote:
Hi Bardo,
The simplest way that I have found to handle json posts is to use the
text generator. Alternatively, you are free to write a json generator
which would convert json to xml as this is the default data format of
cocoon. I have been successfuly using cocoon to handle json (the
contemporary data format of choice) for a few years now. Very recently
I have been using cocoon as middleware between a datasource and Cube.
This Node.js app front ends mongodb using json as the transport over
http. Cocoon still rocks in this new world. Please get in touch if
there is anything I can help with. Best regards Warrell
On 16 Mar 2014 19:37, Bardo Nelgen
mailing.list.in...@bnnperformances.de
mailto:mailing.list.in...@bnnperformances.de wrote:
Hi all,
has someone ever accessed the message body of a post request to
cocoon which uses application/json as its content type?
The same request is being handled without issues if posted as
application/x-www-form-urlencoded.
Though, as soon as the content type is changed to JSON, Cocoon
appears to skip parsing the message body.
Unfortunately it's not me making these POST calls; which is why
just switching it is not an option.
Is there some setting which can tell cocoon to simply continue
parsing, either regardless of a post's content type (which, of
course might raise security issues...) or explicitly for
application/json ?
Any suggestions are welcome.
Regards,
Bardo
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
mailto:users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
mailto:users-h...@cocoon.apache.org
Accessing application/json message body of POST request
Hi all, has someone ever accessed the message body of a post request to cocoon which uses application/json as its content type? The same request is being handled without issues if posted as application/x-www-form-urlencoded. Though, as soon as the content type is changed to JSON, Cocoon appears to skip parsing the message body. Unfortunately it's not me making these POST calls; which is why just switching it is not an option. Is there some setting which can tell cocoon to simply continue parsing, either regardless of a post's content type (which, of course might raise security issues…) or explicitly for application/json ? Any suggestions are welcome. Regards, Bardo - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Wildcard URI Matcher Issue with Cocoon 2.2
Hi all, has anyone ever experienced a kind of mismatch, when a request of type /*/devices/*/registrations/*/* gets a response from a matcher style /*/devices/*/registrations/* ?? Shouldn't actually the first pattern's *last* slash prevent this from happening!? At least that's the way I understood the docs. And, if the above is correct, how can I get around the issue? Unfortunately, the URL construct is the one called by default by Apple Passbook, so I have no influence on the pattern the request comes in… Any insight is warmly welcomed. Best, Bardo - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Wildcard URI Matcher Issue with Cocoon 2.2
Hi all, has anyone ever experienced a kind of mismatch, when a request of type /*/devices/*/registrations/*/* gets a response from a matcher style /*/devices/*/registrations/* ?? Shouldn't actually the first pattern's *last* slash prevent this from happening!? At least that's the way I understood the docs. And, if the above is correct, how can I get around the issue? Unfortunately, the URL construct is the one called by default by Apple Passbook, so I have no influence on the pattern the request comes in… Any insight is warmly welcomed. Best, Bardo - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Remove XML declaration and html DOCTYPE
Thanks nonetheless for the response, Thorsten. The problem is: It won't work for me. While the XML-declaration, indeed, disappears completely with the approach, the doctype remains there. http://www.cityapi.eu/semaworx/MyCompressed.js The mime-type is not additionally declared in the serialize element, since (as earlier posts suggested…) I went with defining a separate serializer: map:serializer logger=sitemap.serializer.text mime-type=application/ecmascript name=js src=org.apache.cocoon.serialization.TextSerializer encodingUTF-8/encoding omit-xml-declarationtrue/omit-xml-declaration /map:serializer and inside the pipeline map:serialize type=js map:parameter name=omit-xml-declaration value=yes/ /map:serialize And despite the charset-entry, the resulting file is also still being shipped as ISO-8859-15 rather than utf-8. I'm sure, I'm missing something here – just don't know, what it is… On 22.08.13 12:01, Thorsten Scherler wrote: On this eMail the reason why top posting is not such a good idea for ml. I have no clue about the context. However map:serialize type=text will return mime-type=text/plain You want mime-type=application/json map:serialize type=text mime-type=application/json map:parameter name=omit-xml-declaration value=yes/ /map:serialize HTH On 08/21/2013 11:18 PM, Bardo Nelgen wrote: Hi all, sorry to pick this up again so late, but is there a solution for Cocoon 2.2 as well? Tried both approaches without the desired result, for a piece of generated JavaScript… As the XML serialization did not work as advertised in this thread so far, I'm currently going with map:serialize type=text and keep getting http://www.cityapi.eu/semaworx/MyCompressed.js Looking for ideas on how to make the Doctype disappear *without* running an extra XSLT cycle? Any hint is appreciated!! Best, Bardo On 19.06.13 18:55, Mansour Al Akeel wrote: map:parameter name=omit-xml-declaration value=yes/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Remove XML declaration and html DOCTYPE
Hi all, sorry to pick this up again so late, but is there a solution for Cocoon 2.2 as well? Tried both approaches without the desired result, for a piece of generated JavaScript… As the XML serialization did not work as advertised in this thread so far, I'm currently going with map:serialize type=text and keep getting http://www.cityapi.eu/semaworx/MyCompressed.js Looking for ideas on how to make the Doctype disappear *without* running an extra XSLT cycle? Any hint is appreciated!! Best, Bardo On 19.06.13 18:55, Mansour Al Akeel wrote: map:parameter name=omit-xml-declaration value=yes/ - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: enter key
Hi Paul, that one's actually quite simple: With all browsers I know the ENTER key-click is auto-associated with a form's HTML SUBMIT input type. That way it will, in essence, work automatically (a.k.a. by default) once your form has a submit button and, as a consequence, not necessarily do so, if you e.g. submit the form via a regular (JavaScript-)link or any other type of scripting. So in case of doubt go for a styled SUBMIT-button and catch the submit event to do your script work (if any), rather than linking to the script function from a button image. Best, Bardo Am 21.12.2012 00:06, schrieb Paul Joseph: Hi there, On some of my forms when I click the Enter key, nothing happens. On others though, the form submits itself. I can't find any documentation readily that explains why I see this difference...any pointers would be much appreciated. (Cocoon 2.1.11, Tomcat 7.x) Paul - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org - To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org For additional commands, e-mail: users-h...@cocoon.apache.org
Re: Setting HTTP protocol header LINK using header action
O.k., got it. You simply need to get away from the spec a bit in order
to succeed:
For browser-compatibility's sake instead of writing
map:parameter name=Link value= #60;/images/MyIcon.gif#62;;
rel='shortcut' /
you better skip the inner quotes and go with
map:parameter name=Link value= #60;/images/MyIcon.gif#62;;
rel=shortcut /
or for stylesheets, instead of
map:parameter name=Link value= #60;/styles/default.css#62;;
rel='stylesheet'; media='screen, handheld'; type='text/css' /
better try with
map:parameter name=Link value= #60;/styles/default.css#62;;
rel=stylesheet; media=screen#44;handheld; type=text/css /
instead.
Just in case someone else runs into this.
Am 13.12.2012 22:52, schrieb Bardo Nelgen:
Hi all,
has anyone so far been successful setting a HTTP protocol LINK parameter
(according to http://tools.ietf.org/html/rfc5988#section-5.5 )
using the cocoon header action? Unfortunately the newer response
header transformer doesn't seem to live up to its promises quite yet,
so I'm currently trying with the action.
By now, I've been successful using the following dummy data
map:act type=header
map:parameter name=content-language
value={flow-attribute:locale} /
map:parameter name=author value=BNN /
map:parameter name=revised value=Bardo Nelgen, 2012-09-11 /
map:parameter name=X-content-age value=16 /
map:parameter name=dc.title value={flow-attribute:mtit} /
map:parameter name=Description value={flow-attribute:mdesc} /
map:parameter name=Keywords value={flow-attribute:keys} /
map:parameter name=geo.position value=49.975712,8.11796 /
map:parameter name=ICBM value=49.975712,8.11796 /
/map:act
with all parameters absolutely correctly ending up in the HTTP
response header for the particular request.
Though, as soon as trying with the Link parameter, webbrowsers do not
appear to recognize the result correctly from the resulting output: It
makes it right into the header, though obviously in the wrong format,
leaving me with
Link /images/semawine/RheinhessenWein.gif; rel='shortcut',
/images/semawine/RheinhessenWein.gif; rel='icon',
http://www.semaworx.org/cocoon/semaworx/.html; rel='bookmark',
http://www.semaworx.org/cocoon/semaworx/.html; rel='canonical',
#top; rel='start'; title*=UTF-8'de'zum%20Seitenanfang
Maybe I'm getting something wrong with the syntax at this point…
map:parameter name=Link value=
#60;/images/semawine/RheinhessenWein.gif#62;; rel='shortcut',
#60;/images/semawine/RheinhessenWein.gif#62;; rel='icon',
#60;http://www.semaworx.org/cocoon/semaworx/{1}.html#62;;
rel='bookmark',
#60;http://www.semaworx.org/cocoon/semaworx/{1}.html#62;;
rel='canonical',
#60;#top#62;; rel='start'; title*=UTF-8'de'zum%20Seitenanfang /
Any ideas or guesses on how to get this right are highly appreciated!!
Best,
Bardo
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Setting HTTP protocol header LINK using header action
Hi all,
has anyone so far been successful setting a HTTP protocol LINK parameter
(according to http://tools.ietf.org/html/rfc5988#section-5.5 )
using the cocoon header action? Unfortunately the newer response header
transformer doesn't seem to live up to its promises quite yet, so I'm
currently trying with the action.
By now, I've been successful using the following dummy data
map:act type=header
map:parameter name=content-language value={flow-attribute:locale}
/
map:parameter name=author value=BNN /
map:parameter name=revised value=Bardo Nelgen, 2012-09-11 /
map:parameter name=X-content-age value=16 /
map:parameter name=dc.title value={flow-attribute:mtit} /
map:parameter name=Description value={flow-attribute:mdesc} /
map:parameter name=Keywords value={flow-attribute:keys} /
map:parameter name=geo.position value=49.975712,8.11796 /
map:parameter name=ICBM value=49.975712,8.11796 /
/map:act
with all parameters absolutely correctly ending up in the HTTP response
header for the particular request.
Though, as soon as trying with the Link parameter, webbrowsers do not
appear to recognize the result correctly from the resulting output: It
makes it right into the header, though obviously in the wrong format,
leaving me with
Link /images/semawine/RheinhessenWein.gif; rel='shortcut',
/images/semawine/RheinhessenWein.gif; rel='icon',
http://www.semaworx.org/cocoon/semaworx/.html; rel='bookmark',
http://www.semaworx.org/cocoon/semaworx/.html; rel='canonical',
#top; rel='start'; title*=UTF-8'de'zum%20Seitenanfang
Maybe I'm getting something wrong with the syntax at this point…
map:parameter name=Link value=
#60;/images/semawine/RheinhessenWein.gif#62;;rel='shortcut',
#60;/images/semawine/RheinhessenWein.gif#62;;rel='icon',
#60;http://www.semaworx.org/cocoon/semaworx/{1}.html#62;;rel='bookmark',
#60;http://www.semaworx.org/cocoon/semaworx/{1}.html#62;;rel='canonical',
#60;#top#62;; rel='start';
title*=UTF-8'de'zum%20Seitenanfang /
Any ideas or guesses on how to get this right are highly appreciated!!
Best,
Bardo
-
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
Accessing Sessions
Hi all, how can I obtain a list of a) the current session-id of the current context (hopefully named that right...) b) all currently active sessions from Cocoon via 1. FlowScript 2. inside a generator 3. inside an action ??? Any help highly appreciated. Bardo Nelgen -- --- BNN Performances http://www.wewillwebyou.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing Sessions
Thanks ! Bardo -- --- BNN Performances http://www.wewillwebyou.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing Sessions
Any further ideas on the other aspects, anyone ??? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Calling JAVA-Action from Flow
Hi all, please excuse me, if this is some stupid beginner's question, but I couldn't find anything on this in the archives... I'm doing some serious RDF/XML processing inside an action and would like to control this from Flow, as I am handling the client-communication in flow. Any ideas, how this could be achieved ? All sorts of input are highly appreciated ! Bardo Nelgen -- --- BNN Performances http://www.wewillwebyou.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Calling JAVA-Action from Flow
Hm. This is what I wanted to avoid... ;-) I even thought I had read something about this in some corner of the documentation - but unfortunately cannot re-find it... *grrr* However. Thanks. :-) :-) Bertrand Delacretaz wrote: On 9/7/06, Bardo Nelgen [EMAIL PROTECTED] wrote: ...I'm doing some serious RDF/XML processing inside an action and would like to control this from Flow, as I am handling the client-communication in flow... I don't think this is possible. You could probably call internal pipelines from your action, technically, but I wouldn't recommend that. I'd suggest extracting your processing code from the action, and calling this directly as a Java component from Flow. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- BNN Performances http://www.wewillwebyou.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
