Steve Spicklemire wrote:
> 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.

I'm using this approach. I'm happy with it.

In one current project, I've got nine specialists, twelve ZClasses. I'm
using DTML methods and External methods in the specialists.

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

I'm using this approach. I'm happy with it.

In another current project, I'm building a python product that consists
of a single Specialist, plus some python classes that can act as ZClass
base classes. 

This latter project involves more text processing and python stuff. The
former project involves workflow and flexible presentation.

Steve Alexander
Software Engineer
Cat-Box limited

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to