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
Am 17.09.2007 um 21:10 schrieb 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 migh
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
config
I know what you mean, but the problem is that just because it's FOR the
site as a whole doesn't mean you want it at the root.
Why?
Well the main example I can quote is a client that has breadcrumbs on
the site, and wants certain things to appear somewhere specific in the
navigation of the site.
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 (A
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: [EMAIL PROTECTE
Doyon, Jean-Francois wrote at 2007-9-17 15:10 -0400:
> ...
>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.
But "utilities for a site" have a natural location: the site root.
A "utility" you
Ah, utilities are "placeless" and not location aware.
Hmmm that's too bad :(
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Doyon,
Jean-Francois
Sent: September 17, 2007 13:16
To: Andreas Jung; [EMAIL PROTECTED]
Subject: RE: [Zope-CMF] Design approach q
Ah! The idea of more registries is what I'd have to go with I guess ...
I'll have a look and debate whether it's worth it :)
Thanks for the insight!
J.F.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of yuppie
Sent: September 17, 2007 13:49
To: Zope-CMF Li
Hi!
Doyon, Jean-Francois wrote:
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 supporti
Summary of messages to the cmf-tests list.
Period Sun Sep 16 12:00:00 2007 UTC to Mon Sep 17 12:00:00 2007 UTC.
There were 11 messages: 11 from CMF Unit Tests.
Tests passed OK
---
Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux
From: CMF Unit Tests
Date: Sun Sep 16 21:26:06 EDT 2
The following supporters have open issues assigned to them in this collector
(http://www.zope.org/Collectors/CMF).
Assigned and Open
tseaver
- "CMF needs View-based TypeInformation",
[Accepted] http://www.zope.org/Collectors/CMF/437
- "CachingPolicyManager awareness of File and
12 matches
Mail list logo