I want to retrieve the form fields in the order that they where submitted in the http POST. I know this has been brought up before, and that the answer is "You cant." http://mail.zope.org/pipermail/zope/2005-October/162460.html For zope to refuse to expose this information to me is really quite arrogant and un-unix like behavior. After all unix lets you do "rm -rf /"... Now in addition to that, it happens that I have almost a hundred forms scattered around maybe 50 sites that all used to use the formmail.pl script, that now use our own zope based workalike. That is, it can not "work-alike" because zope discards the information I need to make it so! To painstakingly alter them all to add this sequence ordering information, just because zope refuses to do as every other scripting system out there that I am aware of, is just out of the queston. My best Idea so far, is to use the apache proxying we use anyway, to run all requests to this url through a small perl or php proxy, that ads the ordering info to the POST. Does anyone have any better ideas? Get hold of the original http data somehow and parse them myself? Patch zope to use a dictionary type that keeps order for req.post? Patch zope to save the ordering as a property in req.post? Regards Gaute Amundsen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gaute Amundsen wrote:
I want to retrieve the form fields in the order that they where submitted in the http POST. I know this has been brought up before, and that the answer is "You cant."
http://mail.zope.org/pipermail/zope/2005-October/162460.html
For zope to refuse to expose this information to me is really quite arrogant and un-unix like behavior. After all unix lets you do "rm -rf /"...
The answer isn't arrogant, and we aren't *preventing* you from gaining access to that information. The implementation which we use for extracting the form data from the request is the standard Python 'cgi.py' module: it doesn't preserve that information, so we can't pass it on to you. That we accept this state of affairs is a sign that we don't share your itch, not that we doubt you have it. Given that this is open source, you *can* modify ZPublisher such that it uses a different mechanism to parse the form data, and are free to submit back such a patch to be included in a future Zope release. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFERo7z+gerLs4ltQ4RAl98AKDF3B/ErUoUhrsBjfLiDbeLxLcamwCeNGIT ZGsRGlVaSuv99TFzCxjT+rI= =njQy -----END PGP SIGNATURE-----
On Wednesday 19 April 2006 21:26, Tres Seaver wrote:
Gaute Amundsen wrote:
I want to retrieve the form fields in the order that they where submitted <snip>
The answer isn't arrogant, and we aren't *preventing* you from gaining access to that information. The implementation which we use for extracting the form data from the request is the standard Python 'cgi.py' module: it doesn't preserve that information, so we can't pass it on to you. That we accept this state of affairs is a sign that we don't share your itch, not that we doubt you have it.
Given that this is open source, you *can* modify ZPublisher such that it uses a different mechanism to parse the form data, and are free to submit back such a patch to be included in a future Zope release.
Tres.
I was waiting for that. "fix it yourself". Yes, I know. Maybe I should have said "patronizing" instedad... Zope uses 'cgi.py', that is interesting. Thank you. The rest is, sorry to say it, redundant. Gaute
Gaute Amundsen wrote:
I want to retrieve the form fields in the order that they where submitted in the http POST. I know this has been brought up before, and that the answer is "You cant."
http://mail.zope.org/pipermail/zope/2005-October/162460.html
For zope to refuse to expose this information to me is really quite arrogant and un-unix like behavior. After all unix lets you do "rm -rf /"...
I'd say blaming zope for not reading the docs is somewhat arrogant .-)
Now in addition to that, it happens that I have almost a hundred forms scattered around maybe 50 sites that all used to use the formmail.pl script, that now use our own zope based workalike.
After all, modularized rewrite would not be so bad I guess ;)
That is, it can not "work-alike" because zope discards the information I need to make it so!
To painstakingly alter them all to add this sequence ordering information, just because zope refuses to do as every other scripting system out there that I am aware of, is just out of the queston.
Sorry, not getting the problem. Last time I saw the formholemail.pl, it used named form variables. You can easily access form variables by name in Zope.
My best Idea so far, is to use the apache proxying we use anyway, to run all requests to this url through a small perl or php proxy, that ads the ordering info to the POST.
Does anyone have any better ideas?
Yes. Give the description of your real problem. With more details please! Show example form as it is and where exactly your problem is. I've yet to see a form problem zope cant handle (provided the information is actually sent by the browser) Regards Tino
On Wednesday 19 April 2006 21:47, Tino Wildenhain wrote:
Gaute Amundsen wrote:
I want to retrieve the form fields in the order that they where submitted
I'd say blaming zope for not reading the docs is somewhat arrogant .-)
I have been reading the docs for thee last 3 years my friend. Could you please specify _which_ docs you are refering to here? And what do they say that has a bearing on this? <snip>
To painstakingly alter them all to add this sequence ordering information, just because zope refuses to do as every other scripting system out there that I am aware of, is just out of the queston.
Sorry, not getting the problem. Last time I saw the formholemail.pl, it used named form variables. You can easily access form variables by name in Zope.
Hm.. ok. I have these 100 forms, all over the place. They live in user editable html. To have to track down and alter them all is out of the question. Yet the users expect the form fields to appear in their emails in the order that they put them on the page. You seem to know formmail.pl, so you know that part :)
My best Idea so far, is to use the apache proxying we use anyway, to run all requests to this url through a small perl or php proxy, that ads the ordering info to the POST.
Does anyone have any better ideas?
Yes. Give the description of your real problem. With more details please! Show example form as it is and where exactly your problem is.
How to retrieve the field order from the http post request. I am afraid the problem is as abstract as that. No clever workarounds on the "single form level" will do.
I've yet to see a form problem zope cant handle (provided the information is actually sent by the browser)
Regards Tino
Glad to hear it. Tres Seaver told me that zope uses cgi.py Does that mean that I could override dict in that file, or just for FieldStorage, with something like the Ordered Dictionary described at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/107747 and request.form would keep the order? Or better maybe just modify FieldStorage along similar lines? Gaute
Gaute Amundsen schrieb:
On Wednesday 19 April 2006 21:47, Tino Wildenhain wrote:
Gaute Amundsen wrote:
I want to retrieve the form fields in the order that they where submitted
I'd say blaming zope for not reading the docs is somewhat arrogant .-)
I have been reading the docs for thee last 3 years my friend. Could you please specify _which_ docs you are refering to here? And what do they say that has a bearing on this?
For example how to construct sane formulars? ;)
<snip>
To painstakingly alter them all to add this sequence ordering information, just because zope refuses to do as every other scripting system out there that I am aware of, is just out of the queston.
Sorry, not getting the problem. Last time I saw the formholemail.pl, it used named form variables. You can easily access form variables by name in Zope.
Hm.. ok. I have these 100 forms, all over the place. They live in user editable html.
Bad concept, but there you are. I bet this isnt the only thing you want to change while you go to an application server (like zope).
To have to track down and alter them all is out of the question. Yet the users expect the form fields to appear in their emails in the order that they put them on the page.
Well now thats interesting. I see to: cc: subject: and body elements and their respective form elements. What kind of other order should be preserved? Its does not matter in which order mime-headers appear (in fact you dont even see that in most MUAs)
You seem to know formmail.pl, so you know that part :)
Not the field ordering part. What other elements exist which need to preserve arbitrary ordering? (Beside the effect if you have more then one to: oder more then one body form element (same name) you get a list with ordering preserved obviously.
My best Idea so far, is to use the apache proxying we use anyway, to run all requests to this url through a small perl or php proxy, that ads the ordering info to the POST.
Does anyone have any better ideas?
Yes. Give the description of your real problem. With more details please! Show example form as it is and where exactly your problem is.
How to retrieve the field order from the http post request.
No, thats not your problem. Thats the solution you are seeking to what you think is your problem :-) Maybe it is maybe not. Please show us an example of the situation you are facing. I believe there can be a simpler solution to it. Regards Tino Wildenhain
On Thursday 20 April 2006 12:09, Tino Wildenhain wrote:
Gaute Amundsen schrieb:
On Wednesday 19 April 2006 21:47, Tino Wildenhain wrote:
Gaute Amundsen wrote:
I want to retrieve the form fields in the order that they where submitted
I'd say blaming zope for not reading the docs is somewhat arrogant .-)
I have been reading the docs for thee last 3 years my friend. Could you please specify _which_ docs you are refering to here? And what do they say that has a bearing on this?
For example how to construct sane formulars? ;)
Being didactic now eh? ;) Well, yes, formularor is quite nice for example, but this is "someone elses mess", and my job :( <snip>
Hm.. ok. I have these 100 forms, all over the place. They live in user editable html.
Bad concept, but there you are. I bet this isnt the only thing you want to change while you go to an application server (like zope).
We have been on zope for years, we just wanted to tighten down the security after one rather nasty attack, and formmail.pl was the only cgi on the server. User editable forms the "right way", now that is another story. I think I have settled on a "separate forms editor" approach, but that is still in the future.
To have to track down and alter them all is out of the question. Yet the users expect the form fields to appear in their emails in the order that they put them on the page.
Well now thats interesting. I see to: cc: subject: and body elements and their respective form elements. What kind of other order should be preserved? Its does not matter in which order mime-headers appear (in fact you dont even see that in most MUAs)
You missunderstand again I'm afraid. I didn't think I was being that brief.. The order of the form elements that goes into mail headers is ofcourse irelevant. I'ts the rest of the form, you know name, adress, street, etc. that are the problem. It's a purely visual thing, but when you have a form with perhaps 50 fields, that the client has carefully grouped and ordered, they can get rather pissed if you try to tell them they can only have it in semi-random or alpabetic in their mail.
You seem to know formmail.pl, so you know that part :)
Not the field ordering part. What other elements exist which need to preserve arbitrary ordering? (Beside the effect if you have more then one to: oder more then one body form element (same name) you get a list with ordering preserved obviously.
My best Idea so far, is to use the apache proxying we use anyway, to run all requests to this url through a small perl or php proxy, that ads the ordering info to the POST.
Does anyone have any better ideas?
Yes. Give the description of your real problem. With more details please! Show example form as it is and where exactly your problem is.
How to retrieve the field order from the http post request.
No, thats not your problem. Thats the solution you are seeking to what you think is your problem :-) Maybe it is maybe not. Please show us an example of the situation you are facing. I believe there can be a simpler solution to it.
Regards Tino Wildenhain
A smiley or two helps, but now I would say you are bordering on arrogant. What more do I have to explain to convince you that I understand what the problem is? Gaute
Gaute Amundsen schrieb: ...
The order of the form elements that goes into mail headers is ofcourse irelevant. I'ts the rest of the form, you know name, adress, street, etc. that are the problem. It's a purely visual thing, but when you have a form with perhaps 50 fields, that the client has carefully grouped and ordered, they can get rather pissed if you try to tell them they can only have it in semi-random or alpabetic in their mail. ... A smiley or two helps, but now I would say you are bordering on arrogant. What more do I have to explain to convince you that I understand what the problem is?
We would have saved time if you provided the very usefull information first :-) Now you are building some kind of table/list with form-field-name: form-field-value - am I right? how is it supposed to handle checkboxes, radiobuttons and select fields? One possible workaround, if you dont want to touch ZPublishers form handling would be to run a script to not only update the forms target (formmail.pl -> zopeform) but split every form element from <input type="text" name="foo" value="" /> into <input type="hidden" name="body.name:records" value="foo"/> <input type="text" name="body.value:records" value="" /> which you easily get as list of name/value pairs in the form variable "body". You can even make this transformation any time a user edits her HTML source - save the users source in a property and transform this source via some regex or HTML parser to what you really want here. Moderate work and you can even add some sanity checks :-) If you can provide some typical samples of the HTML you are facing I believe you even can get help with the transformation script. Regards Tino
On Thursday 20 April 2006 15:46, Tino Wildenhain wrote:
Gaute Amundsen schrieb: ...
The order of the form elements that goes into mail headers is ofcourse irelevant. I'ts the rest of the form, you know name, adress, street, etc. that are the problem. It's a purely visual thing, but when you have a form with perhaps 50 fields, that the client has carefully grouped and ordered, they can get rather pissed if you try to tell them they can only have it in semi-random or alpabetic in their mail.
...
A smiley or two helps, but now I would say you are bordering on arrogant. What more do I have to explain to convince you that I understand what the problem is?
We would have saved time if you provided the very usefull information first :-)
Well, it's amazing how what seems clear to one can be quite opaque to another. I will try to be more explicit next time.
Now you are building some kind of table/list with form-field-name: form-field-value - am I right?
how is it supposed to handle checkboxes, radiobuttons and select fields?
Hm.. I can't recall how I did that. I just made a reiplemetation of how formmail.pl did it. But anything it does, it does looping thru request.form, so I dont think this is relevant.
One possible workaround, if you dont want to touch ZPublishers form handling would be to run a script to not only update the forms target (formmail.pl -> zopeform)
I use apache "proxy rewrite" for that, no update needed.
but split every form element from <input type="text" name="foo" value="" />
into
<input type="hidden" name="body.name:records" value="foo"/> <input type="text" name="body.value:records" value="" />
which you easily get as list of name/value pairs in the form variable "body".
You can even make this transformation any time a user edits her HTML source - save the users source in a property and transform this source via some regex or HTML parser to what you really want here.
Moderate work and you can even add some sanity checks :-)
If you can provide some typical samples of the HTML you are facing I believe you even can get help with the transformation script.
Regards Tino
I have considered a number of variations along these lines. Extracting the ordering information and adding a hidden field is also a posibilty. But the potential for messups, and big pain, with a script altering large amounts of user content, is not inconsiderable I would say. I still think my own idea of adding a small proxy to transparently add that "hidden field" is rather more elagant. I expect I will go with Andrew Milton's idea however, since that keeps us inside zope, and seems simpler to implement. I would have prefered to go to the root of the problem, that allways works best in the long run, but it seems I have managed to avoid the effort this time. I still think it is something zope should handle, but for me it is only a sort of medium-term stop-gap measure, so it will do. Thanks for your attention :) Gaute
Gaute Amundsen wrote:
On Thursday 20 April 2006 15:46, Tino Wildenhain wrote:
Gaute Amundsen schrieb: ...
The order of the form elements that goes into mail headers is ofcourse irelevant. I'ts the rest of the form, you know name, adress, street, etc. that are the problem. It's a purely visual thing, but when you have a form with perhaps 50 fields, that the client has carefully grouped and ordered, they can get rather pissed if you try to tell them they can only have it in semi-random or alpabetic in their mail.
...
A smiley or two helps, but now I would say you are bordering on arrogant. What more do I have to explain to convince you that I understand what the problem is?
We would have saved time if you provided the very usefull information first :-)
Well, it's amazing how what seems clear to one can be quite opaque to another. I will try to be more explicit next time.
Now you are building some kind of table/list with form-field-name: form-field-value - am I right?
how is it supposed to handle checkboxes, radiobuttons and select fields?
Hm.. I can't recall how I did that. I just made a reiplemetation of how formmail.pl did it. But anything it does, it does looping thru request.form, so I dont think this is relevant.
One possible workaround, if you dont want to touch ZPublishers form handling would be to run a script to not only update the forms target (formmail.pl -> zopeform)
I use apache "proxy rewrite" for that, no update needed.
but split every form element from <input type="text" name="foo" value="" />
into
<input type="hidden" name="body.name:records" value="foo"/> <input type="text" name="body.value:records" value="" />
which you easily get as list of name/value pairs in the form variable "body".
You can even make this transformation any time a user edits her HTML source - save the users source in a property and transform this source via some regex or HTML parser to what you really want here.
Moderate work and you can even add some sanity checks :-)
If you can provide some typical samples of the HTML you are facing I believe you even can get help with the transformation script.
Regards Tino
I have considered a number of variations along these lines. Extracting the ordering information and adding a hidden field is also a posibilty. But the potential for messups, and big pain, with a script altering large amounts of user content, is not inconsiderable I would say.
I still think my own idea of adding a small proxy to transparently add that "hidden field" is rather more elagant.
I expect I will go with Andrew Milton's idea however, since that keeps us inside zope, and seems simpler to implement.
I would have prefered to go to the root of the problem, that allways works best in the long run, but it seems I have managed to avoid the effort this time.
I still think it is something zope should handle, but for me it is only a sort of medium-term stop-gap measure, so it will do.
Thanks for your attention :)
Gaute
Hi Gaute, I saw this in a Goodman Javascript book "Elements: A collection of all elements w/in a form ... Collection members are sorted in source code order". So, you could standardize a javascript <process> function that loops thru the elements naming each one? If such a thing could work that you just need to include the ../javascript. David
+-------[ Gaute Amundsen ]---------------------- | | Hm.. ok. | I have these 100 forms, all over the place. They live in user editable html. | To have to track down and alter them all is out of the question. | Yet the users expect the form fields to appear in their emails in the order | that they put them on the page. Render the page with the fields filled and convert to text and place in email. -- Andrew Milton akm@theinternet.com.au
On Thursday 20 April 2006 12:15, Andrew Milton wrote:
+-------[ Gaute Amundsen ]----------------------
| Hm.. ok. | I have these 100 forms, all over the place. They live in user editable | html. To have to track down and alter them all is out of the question. | Yet the users expect the form fields to appear in their emails in the | order that they put them on the page.
Render the page with the fields filled and convert to text and place in email.
Hm.. now that is an idea... I would have to depend on referer I guess, but as long as it degraded gracefully.. But, why render the page, when I could just parse it to get the field order? Fun with regexp, or dom :) It would be a bit of overhead, but so would a php proxy, and the few high-use forms I can rewrite anyway. I think we are onto something here :-D Gaute
+-------[ Gaute Amundsen ]---------------------- | On Thursday 20 April 2006 12:15, Andrew Milton wrote: | > +-------[ Gaute Amundsen ]---------------------- | > | > | Hm.. ok. | > | I have these 100 forms, all over the place. They live in user editable | > | html. To have to track down and alter them all is out of the question. | > | Yet the users expect the form fields to appear in their emails in the | > | order that they put them on the page. | > | > Render the page with the fields filled and convert to text and place in | > email. | | Hm.. now that is an idea... | | I would have to depend on referer I guess, but as long as it degraded | gracefully.. | | But, why render the page, when I could just parse it to get the field order? | Fun with regexp, or dom :) Because you can just throw it at the ZPT or DTML engines, convert to text and as a side-effect you get something ready to put into the email? If you want to write your own parser, feel free. -- Andrew Milton akm@theinternet.com.au
On Thursday 20 April 2006 13:23, Andrew Milton wrote:
+-------[ Gaute Amundsen ]----------------------
| On Thursday 20 April 2006 12:15, Andrew Milton wrote: | > +-------[ Gaute Amundsen ]---------------------- <snip> | But, why render the page, when I could just parse it to get the field | order? Fun with regexp, or dom :)
Because you can just throw it at the ZPT or DTML engines, convert to text and as a side-effect you get something ready to put into the email?
If you want to write your own parser, feel free.
I should have suspected :) Any hints to get me statred on the zpt version? Gaute.
+-------[ Gaute Amundsen ]---------------------- | On Thursday 20 April 2006 13:23, Andrew Milton wrote: | > +-------[ Gaute Amundsen ]---------------------- | > | > | On Thursday 20 April 2006 12:15, Andrew Milton wrote: | > | > +-------[ Gaute Amundsen ]---------------------- | <snip> | > | But, why render the page, when I could just parse it to get the field | > | order? Fun with regexp, or dom :) | > | > Because you can just throw it at the ZPT or DTML engines, convert to text | > and as a side-effect you get something ready to put into the email? | > | > If you want to write your own parser, feel free. | | I should have suspected :) | | Any hints to get me statred on the zpt version? I don't know what you have now, so no not really. PageTemplate can be imported from Products.PageTemplates It as a write method that lets you put the html into it. -- Andrew Milton akm@theinternet.com.au
On Thursday 20 April 2006 14:01, Andrew Milton wrote:
+-------[ Gaute Amundsen ]----------------------
| On Thursday 20 April 2006 13:23, Andrew Milton wrote: | > +-------[ Gaute Amundsen ]---------------------- | > | > | On Thursday 20 April 2006 12:15, Andrew Milton wrote: | > | > +-------[ Gaute Amundsen ]---------------------- | | <snip> | | > | But, why render the page, when I could just parse it to get the field | > | order? Fun with regexp, or dom :) | > | > Because you can just throw it at the ZPT or DTML engines, convert to | > text and as a side-effect you get something ready to put into the | > email? | > | > If you want to write your own parser, feel free. | | I should have suspected :) | | Any hints to get me statred on the zpt version?
I don't know what you have now, so no not really.
PageTemplate can be imported from Products.PageTemplates It as a write method that lets you put the html into it.
Thanks. I will get back to the list when I am done, but it may not happen in a few days. Gaute.
Gaute Amundsen schrieb:
On Thursday 20 April 2006 13:23, Andrew Milton wrote:
+-------[ Gaute Amundsen ]----------------------
| On Thursday 20 April 2006 12:15, Andrew Milton wrote: | > +-------[ Gaute Amundsen ]----------------------
<snip>
| But, why render the page, when I could just parse it to get the field | order? Fun with regexp, or dom :)
Because you can just throw it at the ZPT or DTML engines, convert to text and as a side-effect you get something ready to put into the email?
If you want to write your own parser, feel free.
I should have suspected :)
Any hints to get me statred on the zpt version?
No, you would not do this in ZPT. ZPT is the templating engine. You write your logic in python. External Method for example if you dont want to write a complete product. import re fe=re.compile(r"<input.*?name=\"(.*?)\".*?>",re.DOTALL|re.MULTILINE|re.IGNORECASE) def formparser(self): src=self.document_src() if self.has_Property('formelements'): self.manage_changeProperties(formelements=fe.findall(src)) else: self.manage_addProperty('formelements', fe.findall(src), "lines") put this in an external method and call it after the user updated the HTML of her formular on the object (ZPT, DTML) which holds that HTML. When you get the form request, just use something like: [dict(element=e,value=request.form.get(e) for e in context.formdocument.getProperty('formelements') if request.form.has_key(e)] which gives you the form elements in a nice list with their respective values. Advantage: this makes it impossible for an attacker to just supply more/other form fields then originally were in the form. Regards Tino Wildenhain
On Thursday 20 April 2006 17:16, Tino Wildenhain wrote:
Any hints to get me statred on the zpt version?
No, you would not do this in ZPT. ZPT is the templating engine. You write your logic in python. External Method for example if you dont want to write a complete product.
I have the feeling you don't quite understand what Andrew Milton is suggesting. I don't have the time to look into it properly now, but as I understand it, that templating engine can be instantiated independently, and it's methods called with my own data. But thank you for the code and the effort :) I might yet decide to use my own parser to extract the ordering info, but I will try the ZPT engine first. It has the potential to render the form even closer to how the users made the layout, but I must be able to strip out the menus etc. Gaute
Gaute Amundsen wrote at 2006-4-19 19:03 +0200:
I want to retrieve the form fields in the order that they where submitted in the http POST. I know this has been brought up before, and that the answer is "You cant."
You might be able to do it. Try "REQUEST['BODY']". For a "POST" request, it should contain the entity content. Of course, you would have to decode it yourself ;-) -- Dieter
On Thursday 20 April 2006 20:11, Dieter Maurer wrote:
Gaute Amundsen wrote at 2006-4-19 19:03 +0200:
I want to retrieve the form fields in the order that they where submitted in the http POST. I know this has been brought up before, and that the answer is "You cant."
You might be able to do it.
Try "REQUEST['BODY']". For a "POST" request, it should contain the entity content.
Of course, you would have to decode it yourself ;-)
What? It can't be that simple! I thougt I had been poking all around the corners of REQUEST, looking for just somthing like that. Hm.. no. Error Type: KeyError Error Value: 'BODY' Are you sure about this? In that case, any idea why it is missing? We are on Zope 2.7.5-1.fc3, python 2.3.4, behind Apache/2.0.52 Gaute
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gaute Amundsen wrote:
On Thursday 20 April 2006 20:11, Dieter Maurer wrote:
Gaute Amundsen wrote at 2006-4-19 19:03 +0200:
I want to retrieve the form fields in the order that they where submitted in the http POST. I know this has been brought up before, and that the answer is "You cant."
You might be able to do it.
Try "REQUEST['BODY']". For a "POST" request, it should contain the entity content.
Of course, you would have to decode it yourself ;-)
What? It can't be that simple! I thougt I had been poking all around the corners of REQUEST, looking for just somthing like that.
Hm.. no.
Error Type: KeyError Error Value: 'BODY'
Are you sure about this? In that case, any idea why it is missing?
We are on Zope 2.7.5-1.fc3, python 2.3.4, behind Apache/2.0.52
REQUEST.stdin is the actual stream (either a tempfile or a StringIO). You will likely need to rewind it before you can use it. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFESMPV+gerLs4ltQ4RApq9AJ9viWbzERyQJyVzRnL3PXjvtYT5EgCgwm1R 3lLPwcN8DiHBocoIPQDJUBQ= =hZ5X -----END PGP SIGNATURE-----
On Friday 21 April 2006 13:36, Tres Seaver wrote: <snip>
REQUEST.stdin is the actual stream (either a tempfile or a StringIO). You will likely need to rewind it before you can use it.
That seems to work YES. with cgi.parse_qsl I'm practically done already. Only some unicode troubles with norwegian charcters to iron out. Thanks :-D Gaute
participants (6)
-
Andrew Milton -
David H -
Dieter Maurer -
Gaute Amundsen -
Tino Wildenhain -
Tres Seaver