Re: [Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
At 09:14 PM 10/6/00 -0500, Steve Spicklemire wrote: > >OK.. allow me to summarize my very latest thought. Subclassing >is OK withing my own framework. Yep. >It's OK to require users of my >framework to create ZClasses that subclass from my core logic >Python classes, and from DataSkin. Sort of. To be more precise, as a framework provider you may require that participating objects provide a particular interface. The framework user may 1) create a subclass of one of your classes, 2) add an implementation of your interface to an existing class of theirs, or 3) use your class as is, using SkinScript or other means to form an "adapter" between your desired interface and their existing objects. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
> "pje" == Phillip J Eby <[EMAIL PROTECTED]> writes: pje> It is *not* undesirable to have ZClasses be subclasses of pje> your core logic base class. Just make sure they *also* pje> subclass DataSkin, or that you use the metaclass definition pje> stuff above. You've actually got a pretty decent approach pje> going there. Hmmm.. again, maybe I'm reading too much into the DropZone example, but I seem to recall there that subclassing was pretty much explicitly discouraged. Did I misinterpret that? ''' Notice that we do not subclass SkyDiver from a Customer class and a ResourceUser class. What we are doing is saying is that Customer is a role that a Party (person or organization) plays in an accounting system, and ResourceUser is a role that a Party plays in a resource scheduling system. SkyDiver, then should implement a Party interface, allowing it to be used as a Customer or ResourceUser. Thus, SkyDiver can be used by any framework that needs to collaborate with a Party object, although it may have a new role in which the party will be used. For example, if I later add a curriculum management system to cover my skydiver training courses, I will want SkyDiver to fill the Student role. ''' OK.. allow me to summarize my very latest thought. Subclassing is OK withing my own framework. It's OK to require users of my framework to create ZClasses that subclass from my core logic Python classes, and from DataSkin. If we need integration between frameworks, we can handle that in SkinScript to share attributes between Specialist, or anthing else that might be helpful in providing the needed information. Does that sound right? pje> One question, though. Why the derivation from Folder? Oh... this was a case where my object, in addition to 'simple' properties also needed to 'contain' other stuff (files, images and the like...) making it a subclass of folder just got me that ability for 'free'. I could also have used ObjectManager, but making it folder just reduces the amount of 'UI' effort needed for the management interface of the contained stuff. I could have just created a plain folder with the same 'id' as my DataSkin, and 'associated' they two, but it made some sort of sense to keep them all together. -steve ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
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? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
Hi Phillip First of all... please forgive the long message. When I started it was going to be a quick note... now it's turned into a bit of a novel... but you don't have to read it all. ;-> I'm spewing all this out in part to illustrate some of the things I've done 'wrong' so that others might not go down that road... and also... your reaction (if any) to some of the random thoughts popping up here and there would be most welcome... anyway.. here goes OK.. I think this makes sense.. (hmm.. how's *that* for a statement of supreme confidence!) > "pje" == Phillip J Eby <[EMAIL PROTECTED]> writes: pje> As for set/get methods, we usually just define DataSkin pje> property sheets in the ZClass, and use permission mappings to pje> define the read/write permissions for each sheet. We group pje> properties in sheets according to the domain model pje> permissions for access. Then the domain logic methods in the pje> ZClass call propertysheets.sheetname.manage_changeProperties() with pje> keyword parameters to set things. Usually, we have domain pje> specific methods that alter the values of multiple attributes pje> at the same time, using the property sheets. We rarely have pje> code outside of the ZClass directly manipulate attributes. pje> In instances where we've needed to set attributes which are pje> of types not supported by Zope propertysheets, we've had to pje> use ExternalMethods or something similar. In the long run we pje> expect to be able to use PropertyHandlers to do this without pje> dropping down to Python. OK.. let me just make sure I'm understanding you correctly. 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... 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 Aha! I just found part of the magic in "ProductContext.py" lib/python/App/ProductContext.py This is deep magic! But I think I see that you are up to: >From DataSkins.py: class SZHolder: """ """ def __init__(self): ZClassSheets.__init__.im_func(self) self.common=SkinZISS('common') class _ZClass_for_DataSkin: propertysheets = SZHolder() _zclass_ = DataSkin manage_options = () def initialize(context): context.registerZClass(_ZClass_for_DataSkin) So you set up SZHolder to pose as a 'propertysheets' attribute of the ZClass (I'm guessing that im_func(self) is to get around the 'unbound method' ExtensionClass problem.). Then your 'hand creating' the _ZClass_for_DataSkin rather than using 'registerBaseClass' You're also overriding the ZClass 'common' collection of propertysheets with one that will allow both 'regular' ZClass propertysheets, and also Dataskin propertysheets. 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?) This of course begs the question... why do I want to subclass from anything other than DataSkin in the first place? 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...). But in my last project I hadn't figured all that out, so I originally made a layered system something like this: Thing.py -- try: # # if we're running in Zope.. this will work and we can inherit # from OFS.Folder # from OFS.Folder import Folder from Products.ZPatterns.DataSkins import DataSkin class FlexBase( DataSkin, Folder ): pass except: # # if we're testing stand-alone... we can just subclass from an empty class # class FlexBase: def
[Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTWSpecialists? Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?
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] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )