On Sat, 4 Aug 2001 15:05:21 +0200, Joachim wrote:

Before that, Tim McLaughlin wrote:

...

I listened in on the chat regarding this and although I think the idea has merit, I'm not sure that it is vitally important right now. It could too quickly turn into a lot of burned time with nothing to show for it.

[...]

One of the important points to make is that ZClasses (or a replacement for them) as well as the security model are frequently used by Zope users (or "configurators") , while the new components model will mainly be a benefit for Zope programmers (i.e. people working on extending Zope rather than just using it). So their impact might be much larger ...

I'm going out on a limb, here. I've got a slightly sketchy understanding of the component architecture, myself. But my impression, from what i do understand, is that it will make it easy to do a lot of the things that bring people to ZClasses, and in a better way. At the least, i think it will significantly reduce the pressures that push people in the direction of ZClasses, and at best, fill in most of the gaps that ZClasses currently fill haphazardly. (In contrast to some other voices at zope corp, i *do* see significant value in ZClasses, as opposed to filesystem products[*]. I've used them in the tracker, a bit in my wiki projects, and in customer projects. So i'm with you in wanting what they offer, and in wanting relief from their shortcomings.) Many fundamentals of the component architecture were born in the CMF. Those of us using the CMF found that several of its features enabled the kinds of things we sought from ZClasses, but in a better organized way. Skins, for instance, provide for through-the-web customization of presentation and steering, as do ZClasses. In conjunction with the types-tool and type factory information, you can connect skin methods (and others) with content types, as ZClasses associate the contained method artifacts with the class. In addition, skins provide a direct development path from through-the-web customization to filesystem-based artifacts, and back. The filesystem connection, alone, is a major win over ZClasses, where people suffer for lack of version control, grepping, and other amenities available to stuff based in the file-system. Fostering of separation between presentation, application, and glue between the two is another great benefit of the CMF skinning model. ZClasses can be used in this model, but many of their virtues are superceded by what's there, and they don't specifically support the separation. Yet another advantage of the component approach is that components, even the service components, are "placeful" - they can be situated anywhere in the object hierarchy. This means you can have the same service, for instance, implemented in different ways for different parts of the folder hierarchy. This is in contrast to the global scope of every ZClass. Skins are just one better-fitting CMF methodology that the content architecture will bring to all of zope. Another is the types-tool, by which methods are dynamically associated with content-types - for refining the uses of existing content types with new functionality, without having to do any application coding. It may turn out that the most profound advancement will be the specification of interfaces to hook things together - that will increase modularity in a way that can make the dream of pervasive reuse real. I may be misjudging from a less-than-thorough understanding of the architecture, or of people's ZClass desires, but i think the component model will provide a platform for doing the kinds of things you want to do with ZClasses, in a more comprehensive and manageable way than ZClasses _can_ allow.

BTW: I missed the chat. Will there be a transscript somewhere on zope.org?

Should be - i'm not sure what the situation is... Ken Manheimer klm@zope.com ([*] Things i like and dislike about ZClasses: i like their through-the-web development access, the ability to collect various artifacts of an application together within a folderish GUI, the implicit packaging of TTW-manageable property sheets and, generally all the stuff they gather together for you. I *don't* like the separation of the artifacts from the filesystem, however, and the many foibles and bugs that make working with ZClasses too unpredictable. And i think their security provisions muddy the security equation, i just don't quite understand it...)