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

[Doyon, Jean-Francois]

Indeed, I suppose that takes care of creation ... I'm more worried about
the expense of looking them up.

Right now I do a catalog query every time I was to get to such an
object, which seems like a lot of overhead.

The componentutility from GS wants the object to be in the root for some
reason (Although from reading the code, it wasn't always so?).

Maybe I can run a provideUtility() on the objects I'm interested in
myself manually ... What is the rational for only supporting objects in
the root?

J.F.

-----Original Message-----
From: zope-cmf-bounces at lists.zope.org
[mailto:zope-cmf-bounces at lists.zope.org] On Behalf Of Andreas Jung
Sent: September 16, 2007 08:05
To: Doyon, Jean-Francois; zope-cmf at zope.org
Subject: Re: [Zope-CMF] Design approach questions: unique content-ish
items?



--On 14. September 2007 15:21:28 -0400 "Doyon, Jean-Francois" 
<jdoyon at NRCan.gc.ca> wrote:

> Hello,
>
> So, I have this situation happen often enough, and I'm not sure what 
> would be the best way to approach it.  The context is a Zope + CMF
> (latest) framework deigned to host multiple sites, but where the 
> content management part is purely internal, we manage sites 
> internally, and the public facing part is not interactive to users, 
> they can't log-in, register, or anything like that.
>
> I have object types that need to exist just once, but need to do much 
> more than a standard tool is expected to.
>
> The basic example is the search functionality and user interfaces.  
> Less obvious is a key feature of one major client site where they have

> a mapping tool (as in geographical maps), and many other parts of the 
> site revolve around it, link to it, etc ... It's in many ways a 
> utility, but also a contentish/fodlerish type!
>
> I cannot assume WHERE such an object might be wanted, one client site 
> could want it in one folder, and another in the root (becaue of 
> navigation, breadcrumbs, individual site layouts, etc ...).

I would create a standard CMF-ish content-type. You can check at
creation time if such an object already exists (through a catalog
search). If yes, you throw an exception, if not you proceed....should be
trivial...

-aj