[Zope-dev] ComponentArchitecture thoughts

Ken Manheimer klm@zope.com
Sun, 5 Aug 2001 17:15:20 -0400 (EDT)


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