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 ...


-----Original Message-----
From: Charlie Clark [mailto:[EMAIL PROTECTED] 
Sent: September 17, 2007 14:20
To: Doyon, Jean-Francois
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.

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

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to