Am 17.09.2007 um 21:10 schrieb Doyon, Jean-Francois:

Let's use the simplest example I can think of: The site search interface.

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.

Charlie Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to