Hi Steve, (and any others who might care to comment....) I've been sorting through old ZPatterns email looking for inspiration and I came upon this:
"Steve" == Steve Alexander <steve@cat-box.net> writes:
Steve> Hi folks, Steve> I've been looking at the DropZone example Phillip Eby Steve> provided on the ZPatterns Wiki. Steve> http://www.zope.org/Members/pje/Wikis/ZPatterns/DropZoneExample Steve> I've decided to start implementing it, so as to give myself Steve> an educational experience in using ZPatterns. Did you get very far with this? I'm still working out the best way to get EMarket to work with ZPatterns in my copious spare time, and I've hit a question... in the original EMarket design Shopper, MarketItem, ShoppingBasket, and ShoppingBasketItem were all classes defined in Python. With ZPatterns I'm moving in a direction in which these will be replaced at runtime with customized objects that will merely play the *role* of Shopper, etc... I see how the data associated with these objects can be virtually provided using SkinScript etc... but I'm a little confused about the methods of these objects. PJE makes it very clear in his DropZone example (cited above) that when you allow objects to 'role play', they do not subclass from anything in particular, but rather just sort of 'drop in' and 'act like' any sort of object they need to, in order to get the job done. However, without subclassing... how do they get the Shopper methods? e.g., one EMarket method might be: aShopper.insertIntoShoppingBasket( mi=aMarketItem, quantity=qty ) One idea that occured to me was to make the specialists 'do' everything. ShopperManager.InsertItemIntoShoppersBasket(shopper=aShopper, mi=aMarketItem, quantity=qty), but this smells a little bit like the 'controller' paradigm that Coad et. al. are so opposed to... It seems like 'big brother' for the ShopperManager to be meddling with the individual items in a shopper's basket... but maybe that's the best way... Anyway.. just fiddling around and looking for ideas... thanks! -steve