Alexander Limi wrote:
> May I use the red flag? :)

Yes, you may :(

> Right now, the problems related to KSS vs. CMF is breaking things that
> are crucial for a beta release. Pretty much everything that is related
> to KSS seems to be broken right now:
> - Inline editing doesn't work
> - Inline validation on edit forms doesn't work
> - Clicking the next/previous links in the calendar doesn't work
> All of these fail with "AttributeError: portal_workflow".
> In general, I expect things to break now and then in this phase, but the
> problem now is that everyone is essentially saying "it's not my fault
> (and I don't know anything about [KSS|Zope 3|Five|CMF|insert technology
> here]" and/or "Rocky said he'd look at it when he had time".

You only need to know about how Acquisition really works. I tried to
explain the problem in my other mail to plone-dev
targeted at fellow developers which might be able to help here.

> I understand that it is a complex problem, and that it's really nobody's
> fault as such — just an unfortunate and unintended side effect of
> updating the CMF infrastructure — which is why we need to pull in the
> same direction on this.
> Is there any way that we can get some of the stakeholders together and
> try attacking the problem from the various fronts at the same time? KSS,
> Five, CMF, who else is needed?

I tried the only approach I could think of besides fixing the problem at
the right level (which I'm not smart enough) and have written something
that I call a guerrilla hack, as it is even more evil than the usual
monkey patches I tend to write.

You can put the attached file into CMFPlone/patches and import it from
the __init__.py to get the desired effect. This hacks the component
registry used in kss.core so it behaves like five.localsitemanager in
regard to utilities and Acquisition. It does only work when you have
exactly one component registry in your portal root and the one from KSS.

As most of the Plone tests are currently broken because of some changes
to the default workflow I couldn't run any tests and did only do some
TTW testing which showed that the hack seems to work in a standard site.

This kind of hack really should be the last resort and I don't want to
see it ship with Plone, but it's better than not shipping Plone at all...

from kss.core import azaxview
from zope.component.interfaces import ComponentLookupError

import Acquisition

_marker = object()

def _wrap(self, comp):
    """Return an aq wrapped component with the site as the parent but
    only if the comp has an aq wrapper to begin with.
    next = self.__bases__[0]
    if Acquisition.interfaces.IAcquirer.providedBy(next):
        parent = Acquisition.aq_parent(next)

        if Acquisition.interfaces.IAcquirer.providedBy(comp):
            base = Acquisition.aq_base(comp)

            if base is not Acquisition.aq_base(parent):
                # If the component is not the cmoponent registry container,
                # wrap it in the parent
                comp = base.__of__(parent)
                # If the component happens to be the component registry
                # container we are looking up a ISiteRoot.
                # We are not wrapping it in itself but in its own parent
                comp = base.__of__(Acquisition.aq_parent(parent))

    return comp

def queryUtility(self, provided, name=u'', default=None):
    comp = self.utilities.lookup((), provided, name, default)
    if comp is not default:
        comp = self._wrap(comp)
    return comp

def getUtility(self, provided, name=u''):
    utility = self.queryUtility(provided, name, _marker)
    if utility is _marker:
        raise ComponentLookupError(provided, name)
    return utility

# Apply guerilla hacks

azaxview.SiteViewComponents.queryUtility = queryUtility
azaxview.SiteViewComponents.getUtility = getUtility
azaxview.SiteViewComponents._wrap = _wrap
Framework-Team mailing list

Reply via email to