I doubt this will break a significant amount of code. The
restriction was removed 5 months ago and AFAICS it was removed to
allow email addresses as IDs. That use case will not be broken if
we disallow again IDs starting with '@'.
It seems that you can reasonably easily apply the "@" restriction in
your own app code under 2.8 and 2.9 until we get around to doing the
"right" thing by making this pluggable via the namechooser thingy,
no? I dunno.
The current set of restrictions is too restrictive for "real world"
use when you use Zope heavily as a "fileserver", say via DAV. I
wouldn't treat the existing or older restrictions as "gospel" as a
result. I had actually been meaning to get around to unrestricting
the set of identifiers in the trunk.
Here's my current monkeypatch to Zope to unrestrict a good number of
characters:
def patch_objectmanager_badid():
""" Causes Zope to be less restrictive in the set of characters it
accepts as valid within object identifiers.
Added as acceptable: []*'!:@&#=+$
"""
import re
acceptable = r'[^a-zA-Z0-9-_~,.$\(\)\[\]\*\'\!\:[EMAIL PROTECTED]&\#\=\+\$
]'
bad_id = re.compile(acceptable).search
import OFS.ObjectManager
OFS.ObjectManager.bad_id = bad_id
The projects that use this patch have been in use for several years;
they predate Five. I of course don't mind continuing to do this, but
I'd hate to have to change it temporarily (to fix this bug which
actually isn't a bug for me because I don't use Five for these
projects) and then change it again when we do the pluggable thing.
I suppose I wouldn't care if the change was isolated to the "bad_id"
regex, given that I replace it anyway.
- C
_______________________________________________
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 )
