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.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to