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, [EMAIL PROTECTED]


_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to