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

[Steve Spicklemire]

>>>>> "pje" == Phillip J Eby <pje@telecommunity.com> 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