[Zope-dev] Re: Comments on ZPatterns

[Phillip J. Eby]

At 03:10 PM 6/28/00 +0100, Chris Withers wrote:
>
>1. Too much jargon... by far... Lots of complicated words that are
>meanlingless to the layman and don't help to convey the concepts.

Yep, like "Acquisition" and "object publishing".  :)  Seriously, that is
very much the level we're talking about here. ZPatterns is an evolution to
Zope's revolution, in the area of web-based application development models.
 Zope says the answer is publishing objects in an environment supporting
acquisition.  The ZPatterns design approach is an attempt to answer to the
question, "So what objects should I publish, and what are the appropriate
uses of acquisition?"  As with Zope itself, it is both a design approach
*and* an implementation toolkit for the approach, which certainly doesn't
help the confusion.  :)  Also, as in the early days of Zope, terminology
evolves and changes as the developers of the concepts seek better ways to
explain them to other people.

As an example, "Specialist" was originally called "Interface" by Ty and I
back around September or so.  It evolved to "Implementation Provider" in
the later part of the year, and "Implementor" by the time of our conference
presentation.  After using that name on the lists a while, and in
developing the ZPatterns code, it became clear that the name still really
sucked and we needed one that made more sense on initially encountering it.
 After considerable brainstorming, the term "Specialist" was born, and on
the whole we're happy with it.  Other terms are still in flux, and many I
hope we can do away with by replacing them with simpler, more powerful
ideas (such as replacing all of the different Trigger and Provider plugins
with a simple declarative scripting syntax that lets you specify the aspect
weaving for your objects).


>2. Feature runaway. It seems every day something new (and more
>confusing) has been added to ZPatterns. I think ZPatterns will only work
>if it is kept as simple and functional as possible. My view (bearing in
>mind my limited understanding ;-) would be to concentrate on Containers,
>Container Groups and Plugins on the one front and Racks, Specialists and
>the various providers and agents on the other.

Been there, done that, actually.  There really hasn't been much change in
ZPatterns from 0.3 to 0.4 in that regard.  Most of the upheaval has been
due to making it possible for the capabilities of "Rackmountables" to be
used in non-rack settings.  This forced some significant generalization of
the model and some extension to the "theory" in the area of the internal
event model (which was previously incomplete and too hardwired).

Believe it or not, in 0.4 I have actually *removed* some previously
existing data management plug-ins.  The acquired attribute provider and
acquired sheet provider classes were replaced with a generic "link to
parent data plug-ins" class, for example.  As Ty mentioned in his post on
this subject, we will be trying to do away with other such features later,
replacing them with general-purpose tools.

Unfortunately, all this evolution makes ZPatterns a moving target for
comprehension at the moment.  In spite of this, my reading of the lists
seems to indicate that there are a few people besides Ty and myself who are
actually achieving results with the framework.  I hope that they can help
to provide more accessible how-to materials, because I'm still very focused
on *finishing* ZPatterns to the level that my "paying job" requires.  And
it's likely going to be a few months before my "paying job" requires that I
have introductory docs available for the tools (although I'd personally
really like to have some available before then).