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
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
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
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
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
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 place
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 PROTECTED]
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
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.
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
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
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
12 matches
Mail list logo
