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
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").
Items 3, 4, and 5 make me want to do is a content-ish object. Which is what
I've done so far.
But, its more generic purpose is essentially as a "utility" for the site, at
least conceptually. The only difference might be that it's NOT placeless.
I however, from a coding perspective, think of it as one. It makes total sense
to say getUtility(IMySearch) for instance. This way I don't care where it is,
and I'll always get it.
There's mechanisms like acquisition, or using superValues() that can achieve
something similar, but sill need the object you're looking for to be in the
acquisition path. Utilities just have a wider scope (the whole site, or even
globally), which seems to make much more sense.
I suppose to me it seems that just because the functionality of a utility might
apply to a whole site, it doesn't mean it doesn't have a user-facing component
such as a UI and hence a "location".
My Search object, which presents a nice user friendly interface, has actions
registered with portal_types and such, might also have methods that I want to
call from somewhere else (i.e. getUtility(IMySearch).lookForSomething()). It
is a fairly hybrid object (logic, and UI, and utilitarian).
Search is easy to imagine in this scenario, but I have a couple of others
scenarios like this, where I have a user facing object/component that has other
parts of the site revolving around it. It's a "visual utility" :) Like I
said, the idea of a "Site Glossary" might also be a good one. There's only
one, it has a search interfaces, shows, results, definitions ... But you might
link to it or use it from anywhere in the site.
I have no one to talk "zope" to with here at work, so sorry to abuse the list!
I'm also learning Zope 3/Component Architecture *through* Zope2/CMF ...
From: Charlie Clark [mailto:[EMAIL PROTECTED]
Sent: September 17, 2007 14:20
To: Doyon, Jean-Francois
Cc: [EMAIL PROTECTED]
Subject: Re: [Zope-CMF] Design approach questions: unique content-ish items?
Am 14.09.2007 um 21:21 schrieb Doyon, Jean-Francois:
> The simple example is the search stuff. I have a search form, search
> results, etc ... build around a content-ish type that in turn uses
> portal_catalog. This type should exist only once in the site. It is
> in many ways a tool, though it has a user oriented web interface. It
> also needs things like DC Metadata support (Corporate policy, ALL our
> web pages must have this), and maybe I want to let a site owner
> configure other properties of their instance of the search engine.
> Of course, I can just try it, but I'm curious as to high level
> thoughts on this type of object, how it can or should be handled, if
> anyone has faced this before and how they approach it, etc ...
> Of course, I can't see any way around utilities needing to be in the
> root :( I suppose I can fake paths and breadcrumbs or some such thing
> if needed ...
It's an intriguing post but I think you need to provide more information on the
objects & methods you want available for your sites.
It sounds a bit like you have something (call it a McGuffin for any film buffs
out there) that is installed in the root so that it should be available for any
lower level item but it should also be customisable in some way. Why is this
different to default instance of the McGuffin installed at root level with
local, customised McGuffins installed lower down the hierarchy? This is
standard way to do things in Zope, ie. you can overwrite the document_view
method of any particular document.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests