At 06:57 AM 10/5/00 -0500, Steve Spicklemire wrote:
This brings up another point.... If I choose 'DataSkin' as a storage class, then my code hits the security system every time a refer to any data (simple types) stored directly in the DataSkin. I can either set __allow_access_to_unprotected_subobjects=1 on each instance, or I can write accessor methods for each attribute, (yuk!, but maybe good in some ways...) or I can ask the integrator to create 'dummy' ZClass(es) even for those racks that they don't want/need to customize (which seems to 'get around' the security system.) I'm curious to know what you folks do here.. do you write accessor methods for every type stored in your DataSkins?
We never use raw DataSkins, first off. We always create a domain-specific ZClass subclassed from DataSkin. In your case, I would suggest simply including such ZClasses with your product to provide the default implementation of your domain and presentation logic. As for set/get methods, we usually just define DataSkin property sheets in the ZClass, and use permission mappings to define the read/write permissions for each sheet. We group properties in sheets according to the domain model permissions for access. Then the domain logic methods in the ZClass call propertysheets.sheetname.manage_changeProperties() with keyword parameters to set things. Usually, we have domain specific methods that alter the values of multiple attributes at the same time, using the property sheets. We rarely have code outside of the ZClass directly manipulate attributes. In instances where we've needed to set attributes which are of types not supported by Zope propertysheets, we've had to use ExternalMethods or something similar. In the long run we expect to be able to use PropertyHandlers to do this without dropping down to Python.