[Zope-dev] ZPatterns.... more thoughts about implimentation of a concrete system...

[Steve Spicklemire]

Every couple of weeks I get a little time to work on this stuff... 
well, it's been a couple weeks. ;-)

I was flailing last time over the issue of how to create objects that
could be 'plugged' into different frameworks cleanly. One problem was
that my existing framework had specific classes of objects that had
specific methods associated with them.... I was having trouble working
out how to use a 'generic' DataSkin in place of a specific object, say
shopper, without having my DataSkin subclass somehow from the original
shopper object. We were batting around the idea of putting the methods
in the Specialist, rather than the object and have the specialist
'reach in and meddle' with the object itself... but now I see another
way..   the generic dataskins could simply acquire the methods that
they need from the specialist.... so rather than:

  MySkinManager.DoSomething( mySkin, etc... )

 it could be

  mySkin = MySkinManager.retrieveObject( theObjectID )
  mySkin.DoSomething( etc... )

 where 'DoSomething' is a method of the Specialist MySkinManager,
 but it is only intended to be used (by acquisition) as a method
 of a 'managed skin...'. 


This all begs some questions....  

(1) Is this 'reasonable'? Is anyone else using methods of specialists
    this way?

(2) is it worth enforcing the use by acquisition? e.g.,

   def DoSomething(self, etc... ):

      """ Do Something Cool.... """


      if hasattr(self, '_isRackMountable'):
         ... continue with something cool... 


      else:
         raise RuntimeError, "Sorry... this method must be acquired by a DataSkin.."

(3) Has anyone found a better way to adorn 'plain' objects with methods?

thanks!
-steve