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 <[EMAIL PROTECTED]> writes:
Steve> Hi folks,
Steve> I've been looking at the DropZone example Phillip Eby
Steve> provided on the ZPatterns Wiki.
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.
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...
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -