[Framework-Team] Re: first merges

[Wichert Akkerman]

It wasn't just you: the whole world was blacklisted. Certainly stopped a
few spammers :). Martin just posted before I made the change.

Wichert.

Previously Hanno Schlichting wrote:
> Good morning :)
> 
> After Wichert was so nice to remove me from the spammer blacklist,
> hopefully my reply comes through this time. I only wonder why Martin
> wasn't blacklisted ;)
> 
> Martin Aspeli wrote:
> > Hanno, as always, you're invaluable!
> > 
> >> Right now there are a bunch of test failures which result in
> >> ComponentLookupErrors. These are due to the missing setup of the local
> >> sitemanager in PloneTestCase (setHooks, setSite and friends). If nobody
> >> else has time to get those fixed, I'll do that tomorrow evening.
> > 
> > Should this just go in PloneTestCase's set-up always? I think so - can
> > anyone think of a reason why it may not be desired?
> > 
> > To be clear, it means setting the Plone site root as the local site for
> > Z3 component lookup, meaning things like getUtility() and the adapter
> > lookups will find local components before global ones. You can still
> > override the site in your own afterSetUp() of course.
> > 
> > We need to ensure this only happens in PTC on 3.0. At least I think it's
> > only relevant to Zope 2.10?
> 
> A normal setup of Plone requires these changes, so these should go into
> PTC, but of course only for Plone >= 3.0.
> 
> This change is actually a bit tricky, as we need to call setSite(portal)
> once the portal itself has been created, but before any other
> GenericSetup import handlers are run, as these might already require the
> site to be in place.
> 
> While the import handlers for plone.app.portlets as well as the one in
> GSLocalAddons currently trick around this, they do it in a way that
> might break quite soon, which is to call getSiteManager with an explicit
> context argument "getSiteManager(context)".
> 
> So the beforeSetUp hook is too early as the site isn't yet there and the
> afterSetUp is too late, as all import handlers are already finished   :(
> 
> >> Some more test failures are due to CMFDiffTool trying an old-style
> >> content installation. All it needs is a new proper GenericSetup
> >> extension profile. Some more exportimport handlers should be written for
> >> CMFEditions as well. I have already started working on them...
> > 
> > Why is CMFDiffTool doing a content installation? And didn't we fix this
> > "old-style" content installation?
> 
> I have no idea why CMFDiffTool needs it's own content type called
> ChangeSet, but it's there and it tries to install it in it's
> Extensions/Install.py.
> 
> Now that fails on the first line as "from Products.CMFCore.TypesTool
> import ContentFactoryMetadata" produces an ImportError. There's not much
> we can do about it, other than taking the opportunity and converting it
> to an extension profile.
> 
> What we fixed are the more common Archetypes helper functions which a
> lot more products should use. But if you do things manually you are on
> your own ;)
> 
> Hanno
> 
> 
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.