On 4/22/07, Tres Seaver <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
> On Apr 19, 12:52 pm, Martin Aspeli <[EMAIL PROTECTED]> wrote:
>> -1 to relying on five.localsitemanager, especially if it means other site
>> managers somewhere inside the CMF site will need to be five.lsm aware.
> Not sure what relying on five.lsm means... because if we don't use
> five.lsm, then having sub-ISite's beneath a CMF site will break the
> site due to the fact that current Five doesn't produce __bases__'s
> properly. This was the primary reason for doing five.lsm, to make
> sure sub-ISite's work.
> In effect, having a cmf portal be an ISite but not having a working
> __bases__ actually does more harm than good.
Subsites are a pretty rare case, actually, and have *no* BBB
considerations, as they weren't really possible before. I wouldn't say
we should hold up anything on that account, if no easy fix is available.
I think sub-ISites are actually going to become quite common (I
believe Plone 3.0 uses them extensively, and other extant products
that utilize local components do as well). Unfortunately, the
interface name ISite was a somewhat poorly chosen one, since it really
has little to do with a Site in the portal sense, but is just a
location where persistent component registrations can happen. I
imagine that complex content objects (blogs, mailing lists, forums)
and features that require placeful configuration (the portlets
infrastructure) will need to allow for local registrations of this
As far as the vote goes:
+1 on undeprecating getToolByName
+1 on removing acquisition wrapping from five.lsm and putting it in
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests