Am 17.09.2007 um 21:10 schrieb Doyon, Jean-Francois:
Let's use the simplest example I can think of: The site search
1) There's the portal_catalog tool, which does many things, but
doesn't do the UI.
2) Presume that a given site only has one site search
3) Presume that you might host many sites, and you might want to
provide some configurable content and/or configuration within the
content of the search UI (DC Metadata and other things?)
4) You need your own code to "wrap" portal_catalog, put a look/
templates to it, customize some search logic, etc ...
5) The location of the search object might be anywhere in the
"folder structure" of a given site (root or otherwise). At least I
do not want to presume as to where a client might want to put it
(beause navigation is usually affected by content structure for
better or worst. As are "breadcrumbs").
I can't see what's wrong with the standard approach to this. You seem
to be able to define your basic functionality very well and also
which aspects of the UI and functionality you wish to make optional
or customisable for site administrators essentially through skinning.
Write a Class to give your McGuffin everything it needs, even if this
is largely inheriting from portal functionality and write the
necessary components such as controllers and templates which can be
customised as required. This would make the object "globally"
accessible via URL traversal, eg. /mcguffin. You would have only one
instance of it but this instance would look and behave differently if
customised lower in the hierarchy. I am not sure how well this would
work with different CMF instances as opposed to subsites but I am
also not so sure from your description whether that is what you want.
I think your attempt to add utility methods to such an object is
confusing and, therefore, probably wrong.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests