[Zope-dev] ZPatterns and "Strategies & Patterns etc...."

[Steve Spicklemire]

Hi Folks,

   Well.. I never heard any comments about my last question.. so I
thought I'd try to frame it differently. I just read Coad's book on
Object Models etc.. and I think I pretty well 'grok' it.. at least
enough to be mildly dangerous. ;-) I'm implementing a project with
ZPatterns and I would like to keep a balance between flexibility and
sanity (and of course performance). I've been using 'raw Specialists'
to keep the number of new classes down to a bearable number, but I'm
beginnnig to thing that Zope would behave itself better if I were to
create Product level sub-classes of Specialist instead. I guess I'd
just like to 'hear' what folks think about these different strategies:

at one end of the spectrum:

1) Use ZClasses and 'out of the box' specialists for 90% of the application.
   Make ZClass and only where python is *required*, use external methods.

at the other end of the spectrum:

10) Use full Python products, possibly subclassed from ZPatterns classes
    (DataSkin, Specialist etc....) and never use ZClasses at all...

and there is the middle ground:

5) Use python products for low level logic. Create overriding methods that 
   can be 'dropped in' at the admin interface level, or in a subclass,
   later to change the behavior (e.g., retrieveItem ). Make ZClass sub-
   classes so that userinterface can be easily modified later, and so
   that persistent propertysheets are easy to add... 

There are problems with each end of this spectrum... 

1) There are still limitations on what you can easily do outside of
   python. PythonMethods are great.... but they have strict security
   limitations that make them cumbersome in some cases.

   When you want to call a method of an object, that is really a 'DTML/Python Method'
   you need to pass along context so you end up with a lot of:

   <dtml-with FooManager>

      <dtml-let theResult="aMethodOfTheFooManager(.... )">


      </dtml-let>

   </dtml-with>

   This seems like a lot of monkey-business just to call a method. Also.. nested
   withs can generate problems with namespace pollution.. and unfortunately 
   performance.

5) Same problems as above when invoking methods that are implemented as 
   DTML/Python Methods.. otherwise.. not too bad.. this is where I'm
   living at the moment. All my DataSkin classes are structured as:

   DataSkin --> myBaseClass -> zSubClassableWrapper -> ZClass

   My Specialists are just plain old Secialists... (here's the problem..
   should they be Python products so that they can have plain 
   Python methods?

10) Everything is defined in Products... harder to integrate into other apps
   since it's hard to override/change methods without modifying source code on
   the file system. I can't believe everyone is doing it this way.. but then
   I con't believe that folks are pushing and popping namespaces all over 
   the place like I seem to in my app.... 

Anyway.. thoughts are appreciated.

;-)

thanks,
-steve