[Zope-PTK] Refactoring PTK, Redux

Kevin Dangoor kid@kendermedia.com
Tue, 13 Jun 2000 21:38:31 -0400


----- Original Message -----
From: "Tres Seaver" <tseaver@digicool.com>
To: "Dan L. Pierson" <dan@sol.control.com>
Cc: <zope-ptk@zope.org>
Sent: Tuesday, June 13, 2000 4:48 PM
Subject: Re: [Zope-PTK] Refactoring PTK, Redux


> > Given the above, it sounds good.  I'm still hoping that it will be
> > possible for a content manager to change the appearance of a type of
> > PortalContent without editing the ZClass itself.  Otherwise sites that
> > host multiple portals can expect problems (BTW: this probably isn't us).
>
> This goal is actually a Hard Problem (TM).  I don't see a general solution
> for this;  a given site could require that each PortalContent class
> in the portal is designed to pick up its skin via acquisition, and perhaps
> supply a default skin to be used as a fallback.

Actually, this particular Hard Problem (you're not going to sue me, are
you?) is the main one that ZPatterns aims to solve. (I'm sure Phillip will
correct me if I get this wrong...)

The idea is this: a piece of PortalContent (can be ZClass or Python) will
subclass DataSkin. It will get certain properties and methods from the
ZClass/python as is normal. Additionally, it will look up the acquisition
chain for a Customizer that knows what to do with that particular kind of
PortalContent. That is where you add your customizations to change the look
and what not. This has nice side effects:

- you can host multiple sites in one ZODB and have different looks and even
additional properties for certain sites
- a single site can easily render News Items differently in one folder vs.
another
- upgrades are easy whether the PortalContent is a ZClass or Python. Just
upgrade the Product. Your customizations are still fine.

And I think, if we play our cards right, we can do this without having a big
separation between what goes in a Portal and what works nicely in standard
Zope. I think it would be a shame if people who develop a Zope product need
to maintain two versions: one for Portals, one for ZopeClassic... or if
people managing Zope sites are forced to use the newer interface just
because they'd like to use some of the PortalContent types.

I've seen quite a few messages lately on the Zope list that imply that there
are people out there running Zope that would like to install something like
the Membership component, but may have no interest in the rest of the CMS. I
really think it is an attainable design goal to make this kind of thing
happen cleanly.

BTW, I think Tres' proposed changes are good ones for now. At the moment,
ZPatterns is not completely ready for what the PTK needs. But, ZPatterns 0.4
should provide what we need to get PortalContent going. Alas, I haven't had
a chance to check out the preview yet...

Kevin