Mailing List Archive: Zope: CMF

Design approach questions: unique content-ish items?

Index | Next | Previous | View Threaded

jdoyon at NRCan

Sep 14, 2007, 12:21 PM

Post #1 of 13 (1610 views)
Permalink

Design approach questions: unique content-ish items?

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

With a mix of permissions, UniqueItem, export/import and so on, I can create objects that can be created only once, and act much like "singletons" but it's tricky and not quite proper ...

Now this utility concept comes along from the CA, and it's very handy.

The big problem for me seems to be that:

- They have to be in the root
- They're really meant for tools

I guess I'm wanting to have an object that is a hybrid tool/contentish object. It provides functionality, but it also has a website visible interface (actions, templates, etc ...). Also, it's not necessarily in the root.

Right now I use the catalog to "find" such objects, which is hardly elegant or efficient.

Also, some parts of these objects are user editable (notably the dublin-core stuff), so I really want it to be at least partially manageable by content managers. They however would never need workflow functionality for example.

The only thought I've had so far is:

- See if I can create a traditional tool, and then extend it with actions, views, etc ... I need to have CMF management interfaces, and have them appear though things like listFolderContents()

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

Thanks, and a good week-end to you all!

Jean-François Doyon
Data Dissemination Division | Division de la diffusion des données
Data Management and Dissemination Branch | Direction de la gestion et de la diffusion des données
Earth Sciences Sector | Secteur des sciences de la Terre
Natural Resources Canada | Ressources naturelles Canada
Ottawa, Canada K1A 0E9
jdoyon [at] nrcan-rncan
Telephone | Téléphone 613-992-4902
Facsimile | Télécopieur 613-947-2410
Teletypewriter | Téléimprimeur 613-996-4397
Government of Canada | Gouvernement du Canada

lists at zopyx

Sep 16, 2007, 5:04 AM

Post #2 of 13 (1546 views)
Permalink

Re: Design approach questions: unique content-ish items? [In reply to]

--On 14. September 2007 15:21:28 -0400 "Doyon, Jean-Francois"
<jdoyon [at] NRCan> 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

jdoyon at NRCan

Sep 17, 2007, 10:15 AM

Post #3 of 13 (1554 views)
Permalink

RE: Design approach questions: unique content-ish items? [In reply to]

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
[mailto:zope-cmf-bounces [at] lists] On Behalf Of Andreas Jung
Sent: September 16, 2007 08:05
To: Doyon, Jean-Francois; zope-cmf [at] zope
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> 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
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

jdoyon at NRCan

Sep 17, 2007, 10:43 AM

Post #4 of 13 (1549 views)
Permalink

RE: Design approach questions: unique content-ish items? [In reply to]

Ah, utilities are "placeless" and not location aware.

Hmmm that's too bad :(

-----Original Message-----
From: zope-cmf-bounces [at] lists
[mailto:zope-cmf-bounces [at] lists] On Behalf Of Doyon,
Jean-Francois
Sent: September 17, 2007 13:16
To: Andreas Jung; zope-cmf [at] zope
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
[mailto:zope-cmf-bounces [at] lists] On Behalf Of Andreas Jung
Sent: September 16, 2007 08:05
To: Doyon, Jean-Francois; zope-cmf [at] zope
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> 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
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
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

y.2007- at wcm-solutions

Sep 17, 2007, 10:48 AM

Post #5 of 13 (1545 views)
Permalink

Re: Design approach questions: unique content-ish items? [In reply to]

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 supporting objects in
> the root?

1.) Registering objects from sub-folders in the root site manager
doesn't work without problems because utilities can't be stored with
acquisition wrappers and the re-wrapping always uses the root as context.

2.) It is possible to add additional site managers to sub-folders. That
works fine, just the GenericSetup support is missing:
http://www.zope.org/Collectors/CMF/500

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

wichert at wiggy

Sep 17, 2007, 10:50 AM

Post #6 of 13 (1552 views)
Permalink

Re: Design approach questions: unique content-ish items? [In reply to]

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
> [mailto:zope-cmf-bounces [at] lists] On Behalf Of Doyon,
> Jean-Francois
> Sent: September 17, 2007 13:16
> To: Andreas Jung; zope-cmf [at] zope
> 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
> [mailto:zope-cmf-bounces [at] lists] On Behalf Of Andreas Jung
> Sent: September 16, 2007 08:05
> To: Doyon, Jean-Francois; zope-cmf [at] zope
> 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> 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
> 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
> 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> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

wichert at wiggy

Sep 17, 2007, 10:50 AM

Post #7 of 13 (1542 views)
Permalink

Re: Design approach questions: unique content-ish items? [In reply to]

jdoyon at NRCan

Sep 17, 2007, 11:06 AM

Post #8 of 13 (1545 views)
Permalink

RE: Re: Design approach questions: unique content-ish items? [In reply to]

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: zope-cmf-bounces [at] lists
[mailto:zope-cmf-bounces [at] lists] On Behalf Of yuppie
Sent: September 17, 2007 13:49
To: Zope-CMF List
Subject: [Zope-CMF] Re: Design approach questions: unique content-ish
items?

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 supporting objects
> in the root?

1.) Registering objects from sub-folders in the root site manager
doesn't work without problems because utilities can't be stored with
acquisition wrappers and the re-wrapping always uses the root as
context.

2.) It is possible to add additional site managers to sub-folders. That
works fine, just the GenericSetup support is missing:
http://www.zope.org/Collectors/CMF/500

Cheers,

Yuppie

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
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
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

charlie at begeistert

Sep 17, 2007, 11:20 AM

Post #9 of 13 (1547 views)
Permalink

Re: Design approach questions: unique content-ish items? [In reply to]

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

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

jdoyon at NRCan

Sep 17, 2007, 12:10 PM

Post #10 of 13 (1547 views)
Permalink

RE: Design approach questions: unique content-ish items? [In reply to]

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]
Sent: September 17, 2007 14:20
To: Doyon, Jean-Francois
Cc: zope-cmf [at] zope
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

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

dieter at handshake

Sep 17, 2007, 12:22 PM

Post #11 of 13 (1548 views)
Permalink

RE: Design approach questions: unique content-ish items? [In reply to]

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 deep inside the site are not "utilities for
a site" but "utilities for part of a site".

--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

jdoyon at NRCan

Sep 17, 2007, 12:35 PM

Post #12 of 13 (1555 views)
Permalink

RE: Design approach questions: unique content-ish items? [In reply to]

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. Because the site search is for the whole site,
doesn't mean the client doesn't want it to look like it's somewhere in a
search folder for instance (maybe other search related things, like the
help, live in this folder too?).

Due to PT's and their nature, navigation tends to be somewhat automated,
so you use location to satisfy navigation.

I understand and agree with the fundamental principle of the root as the
place for site-wide utilities, but I have to balance that with some
real-life practical requirements too :)

If I want to be purist about it, what I might need is fake persistent
"proxy objects", or symlink-style objects, to satisfy those other needs
(the UI side) while still using the useful utility concept
(placeless/root).

Isn't the concept of something site-wide being at the root mostly
motivated because of acquisition though? If you forget about
acquisition (using getUtility() means you're not using it), there's no
reason it HAS to be there, and forcing it there serves little to no
purpose (conceptually, though I understand why they have to be there now
in practice).

Anyways, now that I know how/why they are placeless and understand more
the challenges around them being placeful, I'll have to come up with
something else (either place them in the root and workarounds for
place/navigation, or no utilities at all).

Thanks all!
J.F.

-----Original Message-----
From: Dieter Maurer [mailto:dieter [at] handshake]
Sent: September 17, 2007 15:22
To: Doyon, Jean-Francois
Cc: Charlie Clark; zope-cmf [at] zope
Subject: RE: [Zope-CMF] Design approach questions: unique content-ish
items?

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 deep inside the site are not "utilities for a
site" but "utilities for part of a site".

--
Dieter
_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

charlie at begeistert

Sep 17, 2007, 12:42 PM

Post #13 of 13 (1554 views)
Permalink

Re: Design approach questions: unique content-ish items? [In reply to]

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

I can't see what's wrong with the standard approach to this. You seem
to be able to define your basic functionality very well and also
which aspects of the UI and functionality you wish to make optional
or customisable for site administrators essentially through skinning.

Write a Class to give your McGuffin everything it needs, even if this
is largely inheriting from portal functionality and write the
necessary components such as controllers and templates which can be
customised as required. This would make the object "globally"
accessible via URL traversal, eg. /mcguffin. You would have only one
instance of it but this instance would look and behave differently if
customised lower in the hierarchy. I am not sure how well this would
work with different CMF instances as opposed to subsites but I am
also not so sure from your description whether that is what you want.

I think your attempt to add utility methods to such an object is
confusing and, therefore, probably wrong.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

_______________________________________________
Zope-CMF maillist - Zope-CMF [at] lists
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads