Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009)

Alec Mitchell apm13 at columbia.edu
Fri Aug 7 13:47:46 UTC 2009


On Thu, Aug 6, 2009 at 8:47 AM, David Glick<davidglick at onenw.org> wrote:
> On Aug 6, 2009, at 5:42 AM, Andreas Zeidler wrote:
>>
>> i've just tested linkintegrity in a blob-enabled setup (in order to use
>> the traversal adapter from `plone.app.imaging` in a known to work
>> environment, i.e. plone 3.x) and it turns out that it still has 13 failures
>> — as opposed to the 25 currently seen in tests against plone 4.0.  the
>> remaining 12 failure are very likely due to the "default mime-type issue"
>> (which in turn seems to be caused by the patch in
>> https://bugs.launchpad.net/zope2/+bug/143948 — thanks to david for
>> investigating, btw).
>
> Were you using an svn checkout of linkintegrity?  I adjusted the tests last
> night to specify a 'text/html' mimetype where needed, so if you're using an
> svn checkout then the remaining failures are something else (unless I missed
> an occurrence or two).  Following my changes I was seeing 18 failures for
> linkintegrity with Plone 4.
>
> From the investigating I've done so far, I think there are two main causes
> for the remaining failures:
> - linkintegrity's getObjectsFromLinks method uses OFS traversal, which is
> not aware of IPublishTraverse adapters and therefore does not find image
> scales ... as I've been discussing here
> - The linkintegrity tests try to trick the testrunner into not handling the
> LinkIntegrityNotificationException ... this is no longer working properly in
> Zope 2.12 for some reason.
>
>>> Does anyone know the background or justification for
>>> http://dev.plone.org/old/archetypes/changeset/9318 where the switch to an
>>> IPublishTraverse adapter first happened?  Wichert?
>>
>> since `p.a.blob` currently depends on `p.a.imaging`, which has the same
>> traversal adapter as wichert introduced here, and "image support" will be
>> required for the respective 4.0 plip, this needs to be fixed for
>> linkintegrity to work again anyway.  iow, i'll try to look into it during
>> the sprint...
>
> Yep.  That would be great.
>
>>> Even if we use BaseObject's __getitem__, we probably ought to make the
>>> image scale lookup be adapter-based...I know that Andi has had plans to take
>>> advantage of the IPublishTraverse adapter in plone.app.imaging to override
>>> how scales are found (see
>>> http://svn.plone.org/svn/plone/plone.app.imaging/trunk/src/plone/app/imaging/traverse.py --
>>> but this ImageTraverser isn't actually registered anywhere yet).
>>
>> those plans have long been carried out and the adapter is registered, in
>> fact — see http://dev.plone.org/plone/changeset/27627 :)
>
>
> Ah, my bad...I didn't look carefully enough.
>
>> btw, are there any other reasons/breakages besides the linkintegrity
>> failures?  i suppose i could make the latter aware of the traversal adapter,
>> too.  do we know of any (important) 3rd-party products that rely on being
>> able to traverse to image scales the old way?
>
> I haven't tested, but I presume that anything which does something like
> <tal:block tal:condition="exists:context/image_thumb" tal:replace="structure
> python:context.tag(scale='thumb')"/>
> would break.

Though linkintegrity may be working now, I think the code above would
still fail.  I'd guess there's a lot of code in the wild that uses
path expressions to access image scales by name, and we're breaking
all that code unless we fix this for the general case.  OTOH, we could
simply declare that we're OK with breaking backwards compatibility
here if we have consensus that this is worthwhile.  Perhaps we should
vote on this or discuss on the next call.

Alec




More information about the Framework-Team mailing list