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).