[Zope-PTK] Good Practice?

[Shane Hathaway]

Chris Withers wrote:
> 
> Shane Hathaway wrote:
> > In other words, you want to customize your PTK while keeping the door
> > open for future upgrades.  You have hit on a major problem and the
> > current solution is terribly inadequate IMHO: there is a
> > "refresh_interface" method which wipes out your changes and installs a
> > new interface.
> 
> It's a thorny issue, though, and one which affects any
> code/template/html that is 'supposed' to be customized. Exactly the same
> problem exists with Squishdot. The solution I've been employing is to
> try to have a fixed set of interfaces that change as infrequently as
> possible, and post 'pathces' on a 'How to Upgrade Squishdot' page which
> show how to update the old demo code. Peopel can then feed this into
> their own judgement about what needs to eb placed into their customized
> version.

Okay, think in terms of transparent folders.  (See
http://www.zope.org/Members/hathawsh/TransparentFolders ) Note that the
Transparent Folders product is hackish because it works inside any
Folder, but it doesn't have to be hackish at all when the concept is
applied to objects over which we have full control, such as
PortalFolder.

With that in mind, we could create a "portal_skin" component which
contains the interface the user chooses and is easily customizable. 
PortalFolder (or perhaps only PortalObject) would have a __getattr__
method which transparently finds attributes from portal_skin.

Also, all of the default skins might be stored on the filesystem rather
than the ZClass product.  That way we could take advantage of text
merges again.

To clarify how this would look to users, portal_skin would have the
management tabs appropriate for a standard Folder.  The "Properties"
tab, however, would allow you to select the "generic skin".  The
contents of the folder would appear to contain the objects appropriate
for the chosen generic skin, but would not actually contain them unless
the user has done some customization.

Something I hadn't thought of at first is the possibility of multiple
skins (in fact, the word "skin" in this context infers the capability to
handle multiple skins).  In that case, the name of the component would
be "portal_skins".  The UI might be somewhat different.

Shane