[Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!

[Phillip J. Eby]

At 02:24 PM 10/5/00 -0500, Steve Spicklemire wrote:
>
>You're not using propertysheet providers, but DataSkin propertysheets
>'installed' in a ZClass that directly inherits from DataSkin. Your use
>of the "Data Skin Attribute Property Sheets" is primarily to associate
>permissions with groupings of attributes, and to simplify
>establishment and management of those properties through the ZClass
>administrative interface. As a bonus, you get 'free' methods needed to
>adjust these attributes from DTML (i.e., manage_changeProperties) without
>requiring custom PropertyHandlers.

Yes.


>I did notice that when I create a ZClass (in a completely different
>project) that inherits from a Python Product (registered with
>registerBaseClass) that inherits from DataSkin, I don't get the option
>of a DataSkin propertysheet, in the 'common' container of the ZClass,
>so there's probably some manual fiddling I need to do when I register
>my ZClass base class that I'm not doing...

A simple way to avoid this is to simply create the ZClass subclassed from
DataSkin *and* your Python class.


>I'm guessing that the code that defines the SkinZISS, SZHolder, and
>_ZClass_for_DataSkin culminating in registerZClass perform the
>necessary magic to make that happen....

Yes.  If you want to make this work on a Python class, you need to do
something like:

class _ZClass_for_MyClass(_ZClass_for_DataSkin):
    _zclass_ = MyClass

And then in your registration, call:

    context.registerZClass(_ZClass_for_MyClass)

That should be it.


>This is deep magic!

Aye.  Here there be dragons.  :)  Wait'll you see the magic I had to do in
0.4.3 to get ZClass PlugIns and PlugInContainers to work...



>Sooo... if I want my DataSkin subclass to have the same ability
>I'll need to do something similar? (just replace _zclass_ = DataSkin
>with _zclass_ = MyDataSkinSubclass?) 

See above for the shortest way to do this.


>Well.. my *new* strategy (I'm using this on EMarket) is to put all the
>core logic in a Specialist subclass... and let my DataSkins be
>ZClasses that are directly subclassed from __ZClass_for_DataSkin. This
>has its own problems (I still have a hard time working in a
>'specialist' on a method that is supposed to be acquired by a
>DataSkin, and keeping track of who 'self' is and what properties I can
>really get to etc...). 

Personally, I don't recommend this approach, even if you end up with a
ZClass that doesn't do much besides have a propertysheet or two.


>Why did I do all that? I am used to a development routine where I work
>a while... in emacs.. then hit ctrl-c ctrl-c which 'runs' the current
>module. With this setup, everything in Thing.py can work without
>Zope. All my core logic can be tested and I can verify that it works
>correctly *before* I layer all the ZClass stuff on top. (I know..  now
>I guess I need to learn to use ZPublisher/Client.py ;->) Of course
>this requires that my ZClasses are subclasses of my core logic base
>class.. and I now understand why that is generally undesirable. (It
>makes integrating frameworks later more difficult.... ) But there is a
>clear advantage... I think that with the flexibility of Racks and
>SkinScript you could probably even have the best of all possible
>worlds...

It is *not* undesirable to have ZClasses be subclasses of your core logic
base class.  Just make sure they *also* subclass DataSkin, or that you use
the metaclass definition stuff above.  You've actually got a pretty decent
approach going there.

One question, though.  Why the derivation from Folder?