[z3-five] Deprecating the old local site support

[Philipp von Weitershausen]

Lennart Regebro wrote:
> On 7/26/06, Lennart Regebro <regebro at gmail.com> wrote:
>> Geez. I'm sleepy or something. I ment *for* 2.11. :-)
> 
> That is *removing it* in 2.11. But it might be possible that we can
> improve compatibility, in steps.
> 
> I did some quick tests, and I think it would be possible to have
> Five.site be just a thin layer on top of Five.component.

That's cool.

> However, the same incompatibilities arise.

I suspect you're talking about the acquisition wrapping of utilities. I
think that we really want persistent local utilities to be acquisition
wrapped in Zope 2, perhaps because of security, but probably also
because of the migration path ahead: if CMF tools become Zope 3
utilities, we can't ditch aquisition. I suspect CMF tools heavily depend
on being able to acquire things.

Here's what I suggest:

Five.component will supply new component registry called
PersistentAcquiredComponents. It will inherit from
zope.component.persistentregistry.PersistentComponents and basically
just always return the thing they're looking up with an acquisition
context IF the thing they found supports acquisition. Basically, each of
their method will be:

  def querySomething(self, *args, **kwargs):
      ob = super(...).querySomething(*args, **kwargs)
      if hasattr(ob, '__of__'):
          return ob.__of__(self.__parent__)
      return ob

  (the generators look a bit more complicated, but use the same
   princple)

This requires PersistentAcquiredComponents to have a __parent__
attribute which will point to the site that it's associated with. So,
basically, when making a new site, you will do:

  >>> sm = PersistentAcquiredComponents(possible_site)
  >>> possible_site.setSiteManager(sm)
  >>> alsoProvides(possible_site, ISite)

> We keep Five.site around in 2.10, for backwards compatibility with
> 2.9. This means that if you have only software made for
> Five.component, you use it. If you have software *only* made for
> Five.site, you use it. If you have software made for both, you either
> convert Five.site usage to Five.component, or you use Five.site.
> Five.site *should* work with Five.component software as well, but it's
> hard to test that extensively. Local utility usage should be
> compatible over Five 1.2, 1.3, 1.4 and Zope 2.10.
> 
> In Zope 2.11, Five.site gets refactored to be a thin layer around
> Five.component.

That'd be good.

> Software written for Five.site may have to be changed
> a bit. Mainly, utilities will no longer be aq_wrapped.

I think that'd be a BBB foul. Instead of simply dropping aq_wrapping, I
think we should actually support it, even in Five.component.

> The interfaces stay the same, though.

That's awesome.

> In Zope 2.12, Five site gets *Baleeted!* and everybody is happy. :)

In Zope 2.13 you mean. We haven't issued deprecation warnings for
Five.site yet...

Philipp