[Zope3-dev] SVN: Zope3/branches/3.3/ Fixed issues 648 and 593: uploading files with non-ASCII filenames now works.
Hi Marius, Your fix of browser.py causes problems for me using hurry.file when running functional test with zope.testbrowser. The problem is that aFieldStorage.filename is already unicode and it cannot be decoded again. Do you mind if I add an if isinstance(aFieldStorage.filename, unicode): construct? Modified: Zope3/trunk/src/zope/publisher/browser.py === --- Zope3/trunk/src/zope/publisher/browser.py2006-06-13 22:00:47 UTC (rev 68625) +++ Zope3/trunk/src/zope/publisher/browser.py2006-06-14 12:25:49 UTC (rev 68626) @@ -596,7 +596,7 @@ d[m] = getattr(file,m) self.headers = aFieldStorage.headers -self.filename = aFieldStorage.filename +self.filename = unicode(aFieldStorage.filename, 'UTF-8') class RedirectingBrowserRequest(BrowserRequest): Browser requests that redirect when the actual and effective URLs differ -- Best regards, Adam mailto:[EMAIL PROTECTED] -- Quote of the day: We are all dangerous folk without God's controlling hand. - William Ward Ayer ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issues 648 and 593: uploading files with non-ASCII filenames now works.
Hmm, this seems strange to me. How can it be guaranteed that the remote filename is a utf-8 encoded byte string? Not sure this should be done this way anyhow. - Rocky On Mon, 2006-19-06 at 11:01 +0200, Adam Groszer wrote: Hi Marius, Your fix of browser.py causes problems for me using hurry.file when running functional test with zope.testbrowser. The problem is that aFieldStorage.filename is already unicode and it cannot be decoded again. Do you mind if I add an if isinstance(aFieldStorage.filename, unicode): construct? Modified: Zope3/trunk/src/zope/publisher/browser.py === --- Zope3/trunk/src/zope/publisher/browser.py2006-06-13 22:00:47 UTC (rev 68625) +++ Zope3/trunk/src/zope/publisher/browser.py2006-06-14 12:25:49 UTC (rev 68626) @@ -596,7 +596,7 @@ d[m] = getattr(file,m) self.headers = aFieldStorage.headers -self.filename = aFieldStorage.filename +self.filename = unicode(aFieldStorage.filename, 'UTF-8') class RedirectingBrowserRequest(BrowserRequest): Browser requests that redirect when the actual and effective URLs differ -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] About issue 525: i18n Date(time)Widget
Hello! Currently I'm working on the issue 525 (DateWidget ru-format). I've already changed 'parseDatetimetz' in favor of 'self.request.locale.dates.getFormatter' for DatetimeWidget and DateWidget, but now I face some usability/backward compatibility problems. By default display style for 'getFormatter' is set to None which means (in the most locale data files) 'medium' date/time format. The problem is that 'medium' time format doesn't accept timezone argument (in the most locale data files) so there is no way to set timezone information (it just ignored). One possible solution is to change display style to 'long'. The drawbacks I've seen so far are: - the timezone information is mandatory in this case; - the format is much verbose than 'medium'; Maybe some more acceptable solutions exists? In case if there is no objections about 'long' format should we also change display format to 'long' for DateDisplayWidget/DatetimeDisplayWidget? -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Unify the Zope 2 and Zope 3 repositories!
Philipp von Weitershausen wrote: Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore... It's this sort of thing that makes me wish we could unify the source trees... Yes, it might make for a bigger tarball for Zope 3 only folk, but it'd make the release/dependency/etc cycle easier for the larger majority... cheers, Chris - who remembers when Zope 3 was still a CVS branch of Zope 2 ;-) -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Unify the Zope 2 and Zope 3 repositories!
Philipp von Weitershausen wrote: Uh, never mind. +1 :) -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
On 6/19/06, Chris Withers [EMAIL PROTECTED] wrote: Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now. Is it really? That's how it has been so far, yes. Maybe we should extend it. But mind you, that's more work... I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. If somebody else is, fine. Supporting old versions mus reasonably be a I'd suggest there are lots of people still on 2.7.x. When 2.10.x is released imminently, are you saying that everyone will suddenly jump off 2.8.x? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
On 6/19/06, Lennart Regebro [EMAIL PROTECTED] wrote: I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. If somebody else is, fine. Supporting old versions mus reasonably be a Let me continue that. :) Supporting old versions must reasonably be a community effort, depending on if people have the time to do so. We can't just say three versions should be officially supported and then not doing it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] Re: [Zope3-dev] Re: Stable / Development branches?
--On 19. Juni 2006 16:25:32 +0200 Lennart Regebro [EMAIL PROTECTED] wrote: I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. We don't talk about Zope 2.7 which is dead. -aj pgpxH1ETQngYX.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issues 648 and 593: uploading files with non-ASCII filenames now works.
On Mon, 2006-19-06 at 11:01 +0200, Adam Groszer wrote: Hi Marius, Your fix of browser.py causes problems for me using hurry.file when running functional test with zope.testbrowser. The problem is that aFieldStorage.filename is already unicode and it cannot be decoded again. Do you mind if I add an if isinstance(aFieldStorage.filename, unicode): construct? I don't mind, but I think it would be better if testbrowser was changed to match what real browsers do instead. On Mon, Jun 19, 2006 at 08:37:03AM -0230, Rocky Burt wrote: Hmm, this seems strange to me. How can it be guaranteed that the remote filename is a utf-8 encoded byte string? Not sure this should be done this way anyhow. There's an RFC (1867) that says each part in a multipart/form-data request has headers (filename is one of them) that are always 7-bit ASCII and use MIME quoting (RFC 1522, =?charset?encoding?encoded-text?=) if they need to represent non-ASCII characters. Experiments with two real-life browsers (Firefox on Linux, with a UTF-8 system locale, and MSIE 6 on Windows XP with Lithuanian regional settings, which, I presume, mean cp1257) showed that if I upload a filename with non-ASCII characters, I get a UTF-8 encoded str at this point in the code. I assumed that the cgi module from the standard library (that's where the aFieldStorage object comes from) takes care of charset conversions (but didn't actually check that assumption). Modified: Zope3/trunk/src/zope/publisher/browser.py === --- Zope3/trunk/src/zope/publisher/browser.py2006-06-13 22:00:47 UTC (rev 68625) +++ Zope3/trunk/src/zope/publisher/browser.py2006-06-14 12:25:49 UTC (rev 68626) @@ -596,7 +596,7 @@ d[m] = getattr(file,m) self.headers = aFieldStorage.headers -self.filename = aFieldStorage.filename +self.filename = unicode(aFieldStorage.filename, 'UTF-8') class RedirectingBrowserRequest(BrowserRequest): Browser requests that redirect when the actual and effective URLs differ Marius Gedminas -- We have enough youth, how about a fountain of SMART? signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Somebody review my fix for issue 592?
Hi, On Sun, Jun 18, 2006 at 01:33:48AM -0400, Christian Theune wrote: I'm pretty confident that this change does what it is intended to do (fix 592 and some inconsistencies along the way). But as I had to figure out some pretty old code and some of the architecture and dependencies in zope.app.form.browser, I might have made a mistake, although I supplied tests and changed the existing tests according to my view of the world. Here's the changeset for the trunk: http://svn.zope.org/Zope3/trunk/src/zope/app/form/browser/itemswidgets.py?rev=68729view=rev It broke a functional test in one of the packages here. The (no value) option disappeared from the dropdown. It should not have disappeared, because the schema field explicitly says it is not required. (The same thing happens with a real browser.) Reverting the change made in rev 68729 to src/zope/app/form/browser/itemswidgets.py makes the (no value) choice reappear and therefore fixes the problem. I'm still trying to understand why it happens in that view, but not in some other views that also have not-required Choice fields. Marius Gedminas -- If you are smart enough to know that you're not smart enough to be an Engineer, then you're in Business. signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Somebody review my fix for issue 592?
On Mon, Jun 19, 2006 at 07:59:07PM +0300, Marius Gedminas wrote: On Sun, Jun 18, 2006 at 01:33:48AM -0400, Christian Theune wrote: I'm pretty confident that this change does what it is intended to do (fix 592 and some inconsistencies along the way). But as I had to figure out some pretty old code and some of the architecture and dependencies in zope.app.form.browser, I might have made a mistake, although I supplied tests and changed the existing tests according to my view of the world. Here's the changeset for the trunk: http://svn.zope.org/Zope3/trunk/src/zope/app/form/browser/itemswidgets.py?rev=68729view=rev It broke a functional test in one of the packages here. The (no value) option disappeared from the dropdown. It should not have disappeared, because the schema field explicitly says it is not required. (The same thing happens with a real browser.) The problem was that zope.mimetype had its own widget, that subclassed (after a couple of levels of indirection) ItemsEditWidgetBase and overrode renderItemsWithValues. Your changeset shifted the responsibility for rendering the (no value) choice from various renderItems methods into renderItemsWithValues, and zope.mimetype.widget.TranslatableSourceSelectWidget did not expect that. I wonder how many widgets outside the Zope 3 source tree subclass ItemsEditWidgetBase and override renderItemsWithValues... Marius Gedminas -- Stupidity management for the superuser is a user space issue in Unix systems. -- Alan Cox signature.asc Description: Digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Disable developer mode by default
Hi, due to the discussion in issue 507 and to make Zope 3 and Zope 2 behave more similar, I propose to disable the developer mode by default as of Zope 3.3 and as an additional fix for Zope 3.2. Additionally, I might take the time to log a warning when in developer mode, and even more additionally, I'll introduce a red blinking something that tells you in the ZMI that you are running developer mode. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Disable developer mode by default
On 6/19/06, Christian Theune [EMAIL PROTECTED] wrote: Additionally, I might take the time to log a warning when in developer mode, and even more additionally, I'll introduce a red blinking something that tells you in the ZMI that you are running developer mode. +1 to all this! -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re[2]: [Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issues 648 and 593: uploading files with non-ASCII filenames now works.
Hello Benji, Marius,
Sorry, entwarnung
It is hurry.file causing the the problem, it is doing
def _toFormValue(self, value):
if value == self.context.missing_value:
return self._missing
return FileUpload(FakeFieldStorage(value.filename, value.data))
and this FileUpload is trying to do the unicode translation again,
that is causing my problems.
If I do a
return FileUpload(FakeFieldStorage(value.filename.encode('utf-8'), value.data))
my ftests pass again.
Monday, June 19, 2006, 7:21:11 PM, you wrote:
BY Marius Gedminas wrote:
I don't mind, but I think it would be better if testbrowser was changed
to match what real browsers do instead.
BY +1
BY However, we'd have to decide who is creating the unicode string:
BY testbrowser, mechanize, or the publishing framework.
--
Best regards,
Groszer Adam
--
Quote of the day:
Justice is truth in action.
- Joseph Joubert
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
