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?