On Monday, December 3, 2001, at 12:07 PM, Leonardo Rochael Almeida wrote:
Since we are all out complaining about things we'd like to see differently in Zope, let me do my complaining here.
IMO, the string exception problem is one of the worst simptoms of Zope string addiction.
There are way too many parts of Zope that depend on using the right string value. Exceptions and permissions are the worst two, I think.
Zope exceptions should be classes, as seb explained, but ideally the should inherit from a common Zope Exception that is already security declared, so that we can import and catch them in restricted code. I'm tired of writing python scripts that need to do a blind catch because the thing I'm trying to catch is a sligth different form of 'Bad Request' for something as simple as creating an object in a folder that happened to have the same id of an object already there. Any string exception in Zope core or in products should be considered a bug.
Hopefully the publishing machinery will get overhauled enough in Zope 3 to address this. What you're seeing is a long-standing feature of Bobo (aka ZPublisher) that allowed the raising of HTTP 'Exceptions'. When one of these exceptions is raised, the publishing machinery translates it into an appropriate HTTP error code. Since this is such a deep and old feature (written long before class based exceptions were implemented), no one's taken the time to go through and deal with updating them. There are actually a few levels of exceptions possible - standard application level exceptions and the more deliberate protocol based exceptions, such as 'Bad Request', 'Unauthorized', 'Forbidden', etc.
As for permissions, I bet many of you have spent a fair amount of hours debugging a permission problem just to find out that you misspelled or miscapitalized (is that a word?) a permission and created another permission in the process.
I think that permissions should be registered somewhere in order to be used, and the declarative security machinery should barf (or at least complain loudly) at any attempt to protect something with an unregistered permission.
A simple solution that I've found to work decently is to have a 'permissions' module. The CMF does this (Products.CMFCore.CMFCorePermissions). It doesn't really register permissions, but it names them:: ModifyPortalContent = 'Modify Portal Content' Then code that needs to use that permission imports CMFCorePermissions: security.declareProtected(CMFCorePermissions.ModifyPortalContent, 'edit') def edit(self, ...): It's not a perfect solution, but it does work - and it gives a place of reference to discover what the Python name of a permission is. I think the Zope AccessControl package has a similar module now. Moving away from the 'string addiction' is a major effort. I don't know how easily it could be retrofitted into the Zope2 architecture, but I do think this should be a major concern for Zope 3 since the core architecture is going through its first significant overhaul in a very long time. Jeffrey P Shell, jeffrey@cuemedia.com