Chris McDonough wrote:
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?
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.
I'd like to see this improved. But I think we need a solution that works
by default with Zope 3 style views.
Here's my current monkeypatch to Zope to unrestrict a good number of
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.
I'm not concerned about my own app code. I know the problem and how to
And I'm not concerned about people like you who monkeypatch that code.
You know that monkeypatching is always on your own risk and you know how
to modify your monkey patch even if more code is changed than 'bad_id'.
I'm concerned about the people we encourage to use Five technology.
Views are a major feature of Five. Should we warn people not to use
views? Or instruct them how to patch Zope 2 to protect views against
being masked by content IDs?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -