[Zope3-dev] Using classes as constants for security settings
Steve Alexander
steve@cat-box.net
Sun, 17 Feb 2002 13:58:11 +0000
I've been playing around with various ways of getting symbolic constants
that stay constant when you pickle and later unpickle them.
Here's what I've come up with. This works as a replacement for
Zope/App/Security/Settings.py.
----
""" Security setting constants """
class PermissionSettingMetaClass(type):
def __init__(self, name, bases, namespace):
type.__init__(self, name, bases, namespace)
self._name=name
def __str__(self):
return "PermissionSetting: %s" % self._name
def _setDescription(self, description):
self._description=description
def getDescription(self):
return self._description
class PermissionSetting(object):
__metaclass__=PermissionSettingMetaClass
def __init__(self):
raise TypeError, "Cannot instantiate PermissionSettings"
# Explicit allow setting for permissions
class Allow(PermissionSetting): pass
Allow._setDescription("Explicit allow setting for permissions")
# Explicit deny setting for permissions
class Deny(PermissionSetting): pass
# Unset constant that denotes no setting for permission and role
class Unset(PermissionSetting): pass
# Explicit assign setting for roles
class Assign(PermissionSetting): pass
# Explicit remove setting for roles
class Remove(PermissionSetting): pass
----
I have tested this, and several variations.
There will only ever be one Allow class. The FQN of Allow is what gets
stored with pickled objects.
However, we can add methods and descriptions to Allow, and other
permissions, by creating methods in PermissionSettingMetaClass.
We can create __str__ and __repr__ methods on PermissionSettingMetaClass
to make the individual permissions say something meaningful when printed.
The choice for Settings.py is now as follows:
* Numbers for the values of Allow, Deny, Unset etc.
* Strings for the values of Allow, Deny, Unset etc., and we always
compare by equality, not identity
* Classes as symbolic constants, as above. Comparing by identity is
fine.
Any opinions?
--
Steve Alexander