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.
>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
_zclass_ = MyClass
And then in your registration, call:
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
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?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -