[Zope-dev] Re: manage_workspace changes
Hi! Dieter Maurer wrote: Due to a bug in the the condition, however, it redirected for all methods unless they started with a / (reported as a bug in the Zope mailing list). I fixed the condition (patch to collector 1058). Unfortunately, returning getattr(self,method)(self,REQUEST) requires the method to be DTML like and breaks if this is not the case. I now think it is best to *always use the redirect and never return the method. My code now looks like: [...] Thanks! I don't have the time to look into the details. Meanwhile Andreas also stumbled over this issue (with different symptoms, see http://article.gmane.org/gmane.comp.web.zope.plone.user/8507 ) and reverted the manage_workspace changes in CVS. Don't know - if someone checks in your new patch soon (I guess there should be unittests that catch the broken use cases so any future checkins are checked against these use cases.) - if collector #1058 should be reopened - if Zope is currently more broken than before because parts of your patch are still in CVS Cheers, Yuppie ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] __before_publishing_traverse__ problem (2 args only)
Hi, I have a Python product which defines a __before_publishing_traverse_ method. At last I thought it would all work fine now... Now I added one of my User Folder objects and got an exception because __before_publishing_traverse__ was called with only two arguments instead of three. Quite curious (because of course I don't call this method myself) I had a look at ZPublisher/BaseRequest.py, line 251, and noticed it is called there without providing the REQUEST. When I monkeypatched this method to hand over the request as the third argument, Zope complained that the global name 'UNSPECIFIED_ROLES' was not defined (and nothing worked anywhere anymore). So should I make the REQUEST an _optional_ argument to my __before_publishing_traverse__ method? But the purpose of my b.p.t. method is to remove up to two path elements from REQUEST['TraversalRequestNameStack'] and set request variables appropriately, so what is the purpose of this call in BaseRequest? Is there an article anywhere which explains the whole topic in an understandable way? Thanks, Tobias (Zope 2.6.2, ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Making Zope accept international characters in Id's
Hiya everyone!
I didn't get any response on my last post, so I'm charging ahead full speed.
The fact that litmus complains about Zope's inability to accept UTF-8
filenames is something I view as a bug. It can be fixed simply by
changing the default _checkid() implementation to allow extended
characters. However, I don't want to break anything, so I think it
should be optional, controlled by a setting.
Either the already existing, but seemingly undocumented setting
management_page_charset could be used to check that the given Id is
acceptable in that charset.
OR, a separate setting could be used, maybe allowed_id_charset?
I'm gonna go with that last one if nobody complains. Suggested code
(only the important parts):
# Any other characters that should NEVER be
allowed?bad_id=re.compile(r'[:;/\\]').search
def checkValidId(self, id, allow_dup=0):
# So should be allow unicode, then?
if not id or not isinstance(id, StringType):
if isinstance(id, UnicodeType): id = escape(id)
raise BadRequestException, ('Empty or invalid id specified', id)
# Here is the characterset checking. This works fine, I've tried it.
try:
charset = getattr(self, 'allowed_id_charset', 'ascii')
id.decode(charset)
except:
raise BadRequestException, (
'The id %s is not of the allowed character set (%s).' % \
(escape(id), self.allowed_id_charset))
# And here we check for unallowed special characters.
if bad_id(id) is not None:
raise BadRequestException, (
'The id %s contains characters illegal in URLs.' % \
escape(id))
# And then comes the rest of the tests, as usual, for aq_ and such.
# I won't copy them in in this mail.
Opinions?
___
Zope-Dev maillist - [EMAIL PROTECTED]
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] Making Zope accept international characters in Id's
This issue has been discussed several times in the past. There was a
consensus
not allow extended characters because of compatibility issues and
conformance of
the HTTP specs (which don't allow extended chars in URLs AFAIk in unencoded
form).
So it is your task to proof that your implementation works fine, does not
break
compatibility and is compliant with the HTTP specs. I am not against using
extended chars (which would be fine) but there have not been any reasonable
approaches so far AFAIK.
-aj
--On Montag, 20. Oktober 2003 16:01 Uhr +0200 Lennart Regebro
[EMAIL PROTECTED] wrote:
Hiya everyone!
I didn't get any response on my last post, so I'm charging ahead full
speed.
The fact that litmus complains about Zope's inability to accept UTF-8
filenames is something I view as a bug. It can be fixed simply by
changing the default _checkid() implementation to allow extended
characters. However, I don't want to break anything, so I think it should
be optional, controlled by a setting.
Either the already existing, but seemingly undocumented setting
management_page_charset could be used to check that the given Id is
acceptable in that charset.
OR, a separate setting could be used, maybe allowed_id_charset?
I'm gonna go with that last one if nobody complains. Suggested code (only
the important parts):
# Any other characters that should NEVER be
# allowed?bad_id=re.compile(r'[:;/\\]').search
def checkValidId(self, id, allow_dup=0):
# So should be allow unicode, then?
if not id or not isinstance(id, StringType):
if isinstance(id, UnicodeType): id = escape(id)
raise BadRequestException, ('Empty or invalid id specified', id)
# Here is the characterset checking. This works fine, I've tried it.
try:
charset = getattr(self, 'allowed_id_charset', 'ascii')
id.decode(charset)
except:
raise BadRequestException, (
'The id %s is not of the allowed character set (%s).' % \
(escape(id), self.allowed_id_charset))
# And here we check for unallowed special characters.
if bad_id(id) is not None:
raise BadRequestException, (
'The id %s contains characters illegal in URLs.' % \
escape(id))
# And then comes the rest of the tests, as usual, for aq_ and such.
# I won't copy them in in this mail.
Opinions?
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 maillist - [EMAIL PROTECTED]
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] Making Zope accept international characters in Id's
On Monday 20 October 2003 15:01, Lennart Regebro wrote: The fact that litmus complains about Zope's inability to accept UTF-8 filenames is something I view as a bug. does webdav specify how utf-8-encoded dav filenames correspond to file names used in URLs? Either the already existing, but seemingly undocumented setting management_page_charset could be used to check that the given Id is acceptable in that charset. That feature is intended only as an aid for the transition to unicode for users who have content that is stored in an encoded form. OR, a separate setting could be used, maybe allowed_id_charset? If we need to support unicode ids, then the right approach is to allow them to be of unicode type. It looks like OFS has the beginnings of supporting this (as your proposed code fragment pointed out), but Im not aware of it being used. I'm gonna go with that last one if nobody complains. consider this a complaint. character encodings should be applied at zopes boundary, not in the middle of its processing. -- Toby Dickenson ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Reminder: bug day tomorrow Oct 21
Hi all - A quick reminder that we'll be having a bug day tomorrow 10/21 to try to knock out some remaining issues in the drive to get a Zope 2.7 final out. Hope to see you on #zope-bugday ! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Making Zope accept international characters in Id's
Andreas Jung wrote: This issue has been discussed several times in the past. Probably, but infortunately I can't find anything about it. Toby Dickenson wrote: On Monday 20 October 2003 15:01, Lennart Regebro wrote: The fact that litmus complains about Zope's inability to accept UTF-8 filenames is something I view as a bug. does webdav specify how utf-8-encoded dav filenames correspond to file names used in URLs? Good question. If we need to support unicode ids, then the right approach is to allow them to be of unicode type. Ah, yes, of course, you are right. And that requires bigger changes than the suggested, of course. OK, back to the drawing board. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
I've started work on a new-style ExtensionClass. This is a port of ExtensionClass to new-style classes. This will provide a number of advantages: - Use of new-style class features (e.g. descriptors) in Zope objects. - Support for cyclic garbage collection. - Ability to use new-style classes as base classes of Zope objects. - Use of a version of ZODB that supports non-ExtensionClass classes. - Pave the way for sharing code between Zope 2 and Zope 3. I hope I can merge this into the Zope 2 head in a week or two. This is a rather deep change and it is likely to cause some instability on the CVS head for a while. I'm doing this now, rather than later, to give us plenty of time to find and fix problems before a Zope 2.8 release. Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 should be a release that provides *only*: - New-style ExtensionClass, and - ZODB 3.3, featuring multi-version concurrency control, plus any features that have been added to the head since the Zope 2.7 branch was created. This idea is pretty appealing to me. I wonder what others think of it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
On Mon, Oct 20, 2003 at 11:55:39AM -0400, Jim Fulton wrote: I've started work on a new-style ExtensionClass. This is a port of ExtensionClass to new-style classes. This will provide a number of advantages: - Use of new-style class features (e.g. descriptors) in Zope objects. woohoo! this all sounds great. One question about new-style ExtensionClass... I wonder if it will address a minor gripe I have with the current ExtensionClass. I spent a few minutes yesterday debugging some code like this: class FooProduct(SimpleItem): def broken(self, obj): if isintance(obj, FooProduct): # never true! raise TypeError def working(self, obj): if obj.meta_type == FooProduct.meta_type: raise TypeError As it turns out, isinstance(FooProduct(), FooProduct) returns false! AFAICT it's ExtensionClass that is responsible for this surprising behavior. The meta_type approach is a decent workaround, but it means I can't automatically detect all subclasses of FooProduct, which is a nice feature of isinstance. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's MARTIAN TAB GEOLOGIST! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
Jim Fulton wrote at 2003-10-20 11:55 -0400: ... Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 should be a release that provides *only*: - New-style ExtensionClass, and - ZODB 3.3, featuring multi-version concurrency control, plus any features that have been added to the head since the Zope 2.7 branch was created. This idea is pretty appealing to me. I wonder what others think of it. +1 Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] __before_publishing_traverse__ problem (2 args only)
Tobias Herp wrote at 2003-10-20 15:15 +0200: I have a Python product which defines a __before_publishing_traverse_ method. At last I thought it would all work fine now... Now I added one of my User Folder objects and got an exception because __before_publishing_traverse__ was called with only two arguments instead of three. In Products.CMFCore.DynamicType.DynamicType.__before_publishing_traverse I see code like: def __before_publishing_traverse__(self, arg1, arg2=None): Pre-traversal hook. # XXX hack around a bug(?) in BeforeTraverse.MultiHook REQUEST = arg2 or arg1 Apparently, your problem has been observerd by others and they worked around it this way. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Re: manage_workspace changes
Yuppie wrote at 2003-10-20 09:22 +0200: Dieter Maurer wrote: Due to a bug in the the condition, however, it redirected for all methods unless they started with a / (reported as a bug in the Zope mailing list). I fixed the condition (patch to collector 1058). Unfortunately, returning getattr(self,method)(self,REQUEST) requires the method to be DTML like and breaks if this is not the case. I now think it is best to *always use the redirect and never return the method. My code now looks like: [...] Thanks! I don't have the time to look into the details. Meanwhile Andreas also stumbled over this issue (with different symptoms, see http://article.gmane.org/gmane.comp.web.zope.plone.user/8507 ) and reverted the manage_workspace changes in CVS. Don't know - if someone checks in your new patch soon (I guess there should be unittests that catch the broken use cases so any future checkins are checked against these use cases.) I do not think it is useful to check something that definitely can no longer happen. - if collector #1058 should be reopened Let's see whether someone else needs PropertySheets outside ZClasses. - if Zope is currently more broken than before because parts of your patch are still in CVS This is unlikely. We now have again (as before) that (host relative) absolute URLs in manage_options' actions trigger an AttributeError. Few people use absolute URLs in manage_options. If they do, they immediately stop so as it does not work... PropertySheets use absolute URLS but apparently only me and someone else are interested in them. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Reminder: bug day tomorrow Oct 21
I'm getting close to needing to roll out an upgrade for a client site that will need to use python2.2 or . I have zope-2.6.2 working with python2.2.3 but when I try and use python2.3.2 things don't go so well. I'm wondering should I wait for 2.7 (and python2.3.2) or just go with what I have. I would like to roll the upgrade next week (but I might be able to put it off for another week). -EAD On Monday, October 20, 2003, at 10:59 AM, Brian Lloyd wrote: Hi all - A quick reminder that we'll be having a bug day tomorrow 10/21 to try to knock out some remaining issues in the drive to get a Zope 2.7 final out. Hope to see you on #zope-bugday ! Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 maillist - [EMAIL PROTECTED] 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] Re: [Zope-Coders] Reminder: bug day tomorrow Oct 21
On Mon, Oct 20, 2003 at 10:59:38AM -0400, Brian Lloyd wrote: Hi all - A quick reminder that we'll be having a bug day tomorrow 10/21 to try to knock out some remaining issues in the drive to get a Zope 2.7 final out. Hope to see you on #zope-bugday ! isn't it usually #zope-dev? That's what I see on http://dev.zope.org/CVS/BugDays -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's OCTO-MAN! (random hero from isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] Reminder: bug day tomorrow Oct 21
I'm getting close to needing to roll out an upgrade for a client site that will need to use python2.2 or . I have zope-2.6.2 working with python2.2.3 but when I try and use python2.3.2 things don't go so well. I'm wondering should I wait for 2.7 (and python2.3.2) or just go with what I have. I would like to roll the upgrade next week (but I might be able to put it off for another week). You are probably better off sticking with what you have for now - while 2.7 should land soon, I'd be surprised if the final were cut much before the end of November given that there are still some loose ends regarding config installation and the need for at least one more beta (more likely two). Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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] New-style ExtensionClass
On segunda-feira, out 20, 2003, at 13:55 Brazil/East, Jim Fulton wrote: Speaking of Zope 2.8, Jeremy Hylton has suggested that, perhaps, Zope 2.8 should be a release that provides *only*: - New-style ExtensionClass, and - ZODB 3.3, featuring multi-version concurrency control, plus any features that have been added to the head since the Zope 2.7 branch was created. This idea is pretty appealing to me. I wonder what others think of it. I would kill for having that. +1. ~dc ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
