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

[Wichert Akkerman]

You can create local site managers and register utilities there if you
really need more placeful utilities. 

Wichert.

Previously Doyon, Jean-Francois wrote:
> Ah, utilities are "placeless" and not location aware.
> 
> Hmmm that's too bad :( 
> 
> -----Original Message-----
> From: zope-cmf-bounces at lists.zope.org
> [mailto:zope-cmf-bounces at lists.zope.org] On Behalf Of Doyon,
> Jean-Francois
> Sent: September 17, 2007 13:16
> To: Andreas Jung; zope-cmf at zope.org
> Subject: RE: [Zope-CMF] Design approach questions: unique content-ish
> items?
> 
> 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
> 
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests
> _______________________________________________
> Zope-CMF maillist  -  Zope-CMF at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.