[Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On 2008-12-12 16:04:09 +0100, Robert Niederreiter r...@squarewave.at said: Hi, Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick: On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said: Hey, Christian Zagrodnick wrote: [snip] That's good. One thing which is not good is that you deprecated the use of ITerms from zope.app.form. I'd just leave the reference/import there like we did with ISite in zope.app.component. Why is such a deprecation warning bad? Wouldn't this encourage people to update their code? A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 4 OK, 2 Failed
Summary of messages to the zope-tests list. Period Sun Dec 14 12:00:00 2008 UTC to Mon Dec 15 12:00:00 2008 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=2) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:33:54 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010655.html Subject: FAILED (failures=2) : Zope-trunk Python-2.5.2 : Linux From: Zope Tests Date: Sun Dec 14 20:35:24 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010656.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sun Dec 14 20:27:53 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010651.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:29:23 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010652.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:30:54 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010653.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sun Dec 14 20:32:24 EST 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-December/010654.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
Hi Christian Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?] [...] A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. btw, we also should deprecate the ISite interface at the old location. Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Marius Gedminas wrote: doesn't fail with an exception, I can assume that ISomeInterface.providedBy(adapter) ...which in this case should return True, as None does indeed implement the interface in question. *That's* what I'm looking for help with, not judgement on whether adapting to None is a good idea or not ;-) Could you please describe the real problem you're solving? I have a generic IFieldType (well, could arguably be called IFieldValue) adapter, which subclasses, eg: class IFieldType(Interface): pass class number(IFieldType): pass class text(IFieldType): pass class date(IFieldType): pass class empty(IFieldType): pass ...etc.. The idea being that you can do things like: text(anything) ...and if there's an adapter for it, it gets called and you get back something that implements IFieldType. This couples nicely with, for example: classImplements(unicode,text_type) classImplements(int,number_type) classImplements(float,number_type) classImplements(date,date_type) classImplements(type(None),empty) def str_to_date(str): return parse(str,dayfirst=True) provideAdapter(str_to_date,(str,),date) Now, you could, for example, then do: IFieldType([]) ...which should return None. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
Hi Christian Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?] On 2008-12-15 13:44:43 +0100, Roger Ineichen d...@projekt01.ch said: Hi Christian Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?] [...] A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. Depends. See below. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. Yes, for necessary API changes which do not need to be shipped immeadiately I can see that. btw, we also should deprecate the ISite interface at the old location. Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings. All I can say about that is: If there is an improvment in the API we need to announce that. Otherwise other developer will not follow or follow at a time they think it's better for them. Or even worse, they don't know about that. Deprecation messages will kick them a little bit and they get forced to update their code in a acceptable way ;-) The question now is, should we be lazy and skip this information and support nice deprecation free test output or support developer with information about the newest API changes in form of deprecation message hints? Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?]
On 2008-12-15 13:44:43 +0100, Roger Ineichen d...@projekt01.ch said: Hi Christian Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re: zope.browser?] [...] A deprecation warning isn't bad. But I think we should not deprecate the use of ITerms from zope.app.form. I don't see a gain in this API change. Imo it's a bad idea to keep exactly the same interface in 2 places. At least i don't see an improvement or convenience in keeping it. the only real reason to keep it is for legacy reasons, but import adoption should not be that hard ;) No it is not. I just question why we force everybody to use the new location when we did not do so with ISite. It is exactly the same issue with two different outcomes. The canonical location for ISite is zope.location now. It used to reside in zope.app.component but was moved to zope.location w/o deprecating the use from zope.app.location to keep the API backward compatible. I really do not see a differrence to ITerms here. This doesn't have to do with bachward compatibility. Deprecated imports are backward compatible too. I think someone just missed to deprecate that interface. Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html The reason why we should deprecate interfaces is: If a package still points to the old interface location, this package whould bring in the old dependency we tried to remove. Depends. See below. I guess, since you are asking for support the old location, this doesn't hurt you because you are using both packages. Others don't. Any other packages which doesn't adjust the import to the new location will hurt others which do not use both packages. If there is a packe which uses ITerms but not zope.app.form this must be updated then. For packages which use zope.app.form this is not so important. I think they will be updated sooner or later when code is touched anyway because the new import is much shorter. But the deprecation *forces* everybody to update now. And this interface is used in *many* places. I see that this makes it more a good thing for others then for yourself. But I think that's fine. Isn't it? In my point of view, deprecation messages are a great concept to announce changes/improvments without to break compatibility. Without such announcements our code can get very quick out of date and we have no change to know about that. Yes, for necessary API changes which do not need to be shipped immeadiately I can see that. btw, we also should deprecate the ISite interface at the old location. Same question: what would you gain here? Packages are slowly migrated to using the new ISite import but nobody is forced to change all the code right now to get rid of all the deprecation warnings. -- Christian Zagrodnick · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] adapting to None
Chris Withers wrote: Now, you could, for example, then do: IFieldType([]) ...which should return None. I don't understand your example: what is a field type, and why is None somehow a valid field type? Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope] single zsql on multiple tables or multiple zsql s
thanks to Dieter and Peter Bengtsson . Rajasekhar. On Sat, Dec 13, 2008 at 6:30 PM, Peter Bengtsson pete...@gmail.com wrote: Assuming you're developing your product on the filesystem and not inside the ZMI you can use this: http://www.fry-it.com/oss/ZSQL which has some profiling options. 2008/12/12 indrajit926 indra indrajit...@gmail.com: Hi All, In my project iam using zsqls. Now i want to improve performance of project.So i thought to reduce number of zsqls,expecting it may improve performance. using one zsql to fetch values from different tables ,can increase performance ?(instead of using multiple zsqls on multiple tables). Is there anyother ways to improve performance in using zsql.please suggest me if any. Thanks in advance, Raj. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] problem with a form in IE 7
Has nothing to do with Zope but... Use Firefox to debug it and you'll get to see the error. put method=post on form tag and the submission won't be visible in the URL. 2008/12/11 C baiew...@gmail.com: We are running Zope 2.9.8 on Macintosh OS X Server 10.5.5 behind Apache 2.x. I am having a problem when trying to submit one of my forms in IE 7. This only happens on Windows XP and it only started happening recently (we think in the past week). The form contains several select boxes. When the user selects a value from one of the select boxes, it submits the form and processes the selection. The error I receive is an IE error that says:Internet Explorer Cannot Display the Webpage. And for some reason, all of my selectbox values are showing in the URL as parameters. This is not supposed to happen. If I remove the parameters from the URL line and press enter, it works fine. I have another page that works similar to this one (with multiple select boxes that submit the form upon selection), that doesn't experience the same problem. I even changed my form action to go to a plain html page, and it still tries to pass all of my form variables in the URL string. I went to Microsoft's trouble shooting page for this error. I've tried deleting my browser history, clearing out any cached items, and also re-starting IE without Add-Ons. The server has been restarted as well. None of these options have resolved the issue. Neither the Apache log nor the Zope error log shows these errors. Has anyone encountered this problem? If so, what have you done to resolve the issue? ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] problem with a form in IE 7
Quoting Peter Bengtsson pete...@gmail.com: Has nothing to do with Zope but... Use Firefox to debug it and you'll get to see the error. put method=post on form tag and the submission won't be visible in the URL. I've had this happen with method=get in the past. Changing to post fixed it but... May be worth checking zope.conf: Directive: http-header-max-length # # Description: # Maximum number of bytes allowed within a HTTP request header. The request # is discarded and considered as a DoS attack if the header size exceeds # this limit. # # Default: 8192 # # Example: # # http-header-max-length 16384 Regards Garry 2008/12/11 C baiew...@gmail.com: We are running Zope 2.9.8 on Macintosh OS X Server 10.5.5 behind Apache 2.x. I am having a problem when trying to submit one of my forms in IE 7. This only happens on Windows XP and it only started happening recently (we think in the past week). The form contains several select boxes. When the user selects a value from one of the select boxes, it submits the form and processes the selection. The error I receive is an IE error that says:Internet Explorer Cannot Display the Webpage. And for some reason, all of my selectbox values are showing in the URL as parameters. This is not supposed to happen. If I remove the parameters from the URL line and press enter, it works fine. I have another page that works similar to this one (with multiple select boxes that submit the form upon selection), that doesn't experience the same problem. I even changed my form action to go to a plain html page, and it still tries to pass all of my form variables in the URL string. I went to Microsoft's trouble shooting page for this error. I've tried deleting my browser history, clearing out any cached items, and also re-starting IE without Add-Ons. The server has been restarted as well. None of these options have resolved the issue. Neither the Apache log nor the Zope error log shows these errors. Has anyone encountered this problem? If so, what have you done to resolve the issue? ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] problem with a form in IE 7
2008/12/15 ga...@schoolteachers.co.uk: Quoting Peter Bengtsson pete...@gmail.com: Has nothing to do with Zope but... Use Firefox to debug it and you'll get to see the error. put method=post on form tag and the submission won't be visible in the URL. I've had this happen with method=get in the past. Changing to post fixed it but... May be worth checking zope.conf: Directive: http-header-max-length # # Description: # Maximum number of bytes allowed within a HTTP request header. The request # is discarded and considered as a DoS attack if the header size exceeds # this limit. # # Default: 8192 # # Example: # # http-header-max-length 16384 No. Don't fiddle with that. Get the form right. That's the basics. It might be worth reading up and understanding the basic difference between POST and GET and which to use when. Regards Garry 2008/12/11 C baiew...@gmail.com: We are running Zope 2.9.8 on Macintosh OS X Server 10.5.5 behind Apache 2.x. I am having a problem when trying to submit one of my forms in IE 7. This only happens on Windows XP and it only started happening recently (we think in the past week). The form contains several select boxes. When the user selects a value from one of the select boxes, it submits the form and processes the selection. The error I receive is an IE error that says:Internet Explorer Cannot Display the Webpage. And for some reason, all of my selectbox values are showing in the URL as parameters. This is not supposed to happen. If I remove the parameters from the URL line and press enter, it works fine. I have another page that works similar to this one (with multiple select boxes that submit the form upon selection), that doesn't experience the same problem. I even changed my form action to go to a plain html page, and it still tries to pass all of my form variables in the URL string. I went to Microsoft's trouble shooting page for this error. I've tried deleting my browser history, clearing out any cached items, and also re-starting IE without Add-Ons. The server has been restarted as well. None of these options have resolved the issue. Neither the Apache log nor the Zope error log shows these errors. Has anyone encountered this problem? If so, what have you done to resolve the issue? ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] problem with a form in IE 7
It turns out that Internet Explorer doesn't like it when you pass more than 141 form variables with a single submit. Our site collects employment applications and once we hit 142 applications the page broke for anyone using IE7 on XP. On Thu, Dec 11, 2008 at 10:17 AM, C baiew...@gmail.com wrote: We are running Zope 2.9.8 on Macintosh OS X Server 10.5.5 behind Apache 2.x. I am having a problem when trying to submit one of my forms in IE 7. This only happens on Windows XP and it only started happening recently (we think in the past week). The form contains several select boxes. When the user selects a value from one of the select boxes, it submits the form and processes the selection. The error I receive is an IE error that says:Internet Explorer Cannot Display the Webpage. And for some reason, all of my selectbox values are showing in the URL as parameters. This is not supposed to happen. If I remove the parameters from the URL line and press enter, it works fine. I have another page that works similar to this one (with multiple select boxes that submit the form upon selection), that doesn't experience the same problem. I even changed my form action to go to a plain html page, and it still tries to pass all of my form variables in the URL string. I went to Microsoft's trouble shooting page for this error. I've tried deleting my browser history, clearing out any cached items, and also re-starting IE without Add-Ons. The server has been restarted as well. None of these options have resolved the issue. Neither the Apache log nor the Zope error log shows these errors. Has anyone encountered this problem? If so, what have you done to resolve the issue? ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Storing unicode in ZODB objects
Andreas Jung wrote at 2008-12-14 16:00 +0100: On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote: Hey AJ, Thanks. Full traceback below. Regarding storing files, I meant the File Zope Object, as added by the following API call: newFolder.manage_addFile(id,title=title, content_type=text/plain, file=content). 'file' must be an open file object and not a string with the binary content. Almost: file is either a file like object or an str but not unicode. @Thibaud: encode your unicode to a byte sequence (str) using an adequate encoding (e.g. 'utf-8'). You should then also indicate the chosen charset in content_type, e.g. content_type='text/plain; charset=utf-8'. -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] problem with a form in IE 7
On Monday 15 December 2008 15:04, Peter Bengtsson wrote: 2008/12/15 ga...@schoolteachers.co.uk: Quoting Peter Bengtsson pete...@gmail.com: Has nothing to do with Zope but... Use Firefox to debug it and you'll get to see the error. put method=post on form tag and the submission won't be visible in the URL. I've had this happen with method=get in the past. Changing to post fixed it but... May be worth checking zope.conf: Directive: http-header-max-length # # Description: # Maximum number of bytes allowed within a HTTP request header. The request # is discarded and considered as a DoS attack if the header size exceeds # this limit. # # Default: 8192 # # Example: # # http-header-max-length 16384 No. Don't fiddle with that. Get the form right. That's the basics. It might be worth reading up and understanding the basic difference between POST and GET and which to use when. I wasn't suggesting that he fiddles with it, but that someone else may have already fiddled, so therefore to check that the default was still extant. Regards Garry ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Storing unicode in ZODB objects
Hi Dieter,
That makes a lot of sense, thanks. Once I encode the strings in utf-8
there are no issues.
That's a great tip about setting the content_type charset correctly. The
way I was handling this so far was to specify it in the header of the page
that was displaying the text:
span
tal:content=nocall:python:request.response.setHeader('Content-Type','text/html;
charset=UTF-8') tal:omit-tag=/span
But setting the content type is a lot cleaner, so I'll be doing that from
now on.
Thanks!
Thibaud
Also, in case anyone googles this... by default Zope renders content with a
On Mon, Dec 15, 2008 at 2:56 PM, Dieter Maurer die...@handshake.de wrote:
Andreas Jung wrote at 2008-12-14 16:00 +0100:
On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote:
Hey AJ,
Thanks. Full traceback below. Regarding storing files, I meant the File
Zope Object, as added by the following API call:
newFolder.manage_addFile(id,title=title, content_type=text/plain,
file=content).
'file' must be an open file object and not a string with the binary
content.
Almost: file is either a file like object or an str but not unicode.
@Thibaud: encode your unicode to a byte sequence (str)
using an adequate encoding (e.g. 'utf-8').
You should then also indicate the chosen charset in content_type,
e.g. content_type='text/plain; charset=utf-8'.
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Storing unicode in ZODB objects
One more thing... as far as I can tell there is still a need to set the
header through a nocall if try to display your file content as part of a
larger page that is generated with out of the box Page Templates or DTML
methods.
So the call that I pasted below should help if anyone else ever runs into
this...
- Thibaud
On Mon, Dec 15, 2008 at 3:52 PM, Thibaud Morel l'Horset tee...@gmail.comwrote:
Hi Dieter,
That makes a lot of sense, thanks. Once I encode the strings in utf-8
there are no issues.
That's a great tip about setting the content_type charset correctly. The
way I was handling this so far was to specify it in the header of the page
that was displaying the text:
span
tal:content=nocall:python:request.response.setHeader('Content-Type','text/html;
charset=UTF-8') tal:omit-tag=/span
But setting the content type is a lot cleaner, so I'll be doing that from
now on.
Thanks!
Thibaud
Also, in case anyone googles this... by default Zope renders content with a
On Mon, Dec 15, 2008 at 2:56 PM, Dieter Maurer die...@handshake.dewrote:
Andreas Jung wrote at 2008-12-14 16:00 +0100:
On 14.12.2008 15:44 Uhr, Thibaud Morel l'Horset wrote:
Hey AJ,
Thanks. Full traceback below. Regarding storing files, I meant the File
Zope Object, as added by the following API call:
newFolder.manage_addFile(id,title=title, content_type=text/plain,
file=content).
'file' must be an open file object and not a string with the binary
content.
Almost: file is either a file like object or an str but not unicode.
@Thibaud: encode your unicode to a byte sequence (str)
using an adequate encoding (e.g. 'utf-8').
You should then also indicate the chosen charset in content_type,
e.g. content_type='text/plain; charset=utf-8'.
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
