[Zope-CMF] Design approach questions: unique content-ish items?

[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").

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

J.F.

-----Original Message-----
From: Charlie Clark [mailto:charlie at begeistert.org] 
Sent: September 17, 2007 14:20
To: Doyon, Jean-Francois
Cc: zope-cmf at zope.org
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
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226