On Aug 6, 2009, at 5:47 PM, David Glick 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?
yes, i was in fact. but that doesn't matter since i was testing against 3.x anyway. just with `plone.app.imaging` installed, i.e. the (same) traversal adapter enabled.
I adjusted the tests last night to specify a 'text/html' mimetype where needed,
we should not do this. we should really fix the underlying issue instead of adjusting the tests to "cover up"...
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.
hmm, you might have missed a few then. just adding the traversal adapter seems to introduce 13 failures. but 13 or 18, it definitely needs fixing... :)
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
right, but in this case i'd suggest fixing linkintegrity, since requiring something like image scales to be (aq-wrapped) sub-objects doesn't sound right anyway.
- 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.
well, it was a bit of a hack anyway. however, i think in one of the quick tests i did earlier setting `>>> browser.handleErrors = False` solved the issue. i've got no idea why it would, but perhaps you wanna give it a try... or i will :)
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.
i hid it away ;)
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.
yes, it would, of course. however, those should be trivial to fix provided we document it properly. so since we'll need to make that change anyway — or say, we'd really like to — i'd be in favour of doing it now and avoid adding more magic workarounds to make it work both ways...
andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.3rc4 released! -- http://plone.org/products/plone/
Description: This is a digitally signed message part
_______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team