Re: (Was Re: [Framework-Team] Minutes: 8 August 2009)
On 2009-8-6 06:30, David Glick wrote: 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? The reasoning behind that is a) we want to get rid of __bobo_traverse__ methods and b) this change transparently exposes all image where the original code only hardcoded exposure of a field with the name 'iage'. I don't quite see what the problem is with that code; can someone explain that? Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: (Was Re: [Framework-Team] Minutes: 8 August 2009)
On Aug 6, 2009, at 6:30 AM, David Glick wrote: On Aug 5, 2009, at 1:45 PM, Alec Mitchell wrote: On Wed, Aug 5, 2009 at 1:18 PM, David Glickdavidgl...@onenw.org wrote: * IPublishTraverse is used where ITraverse should be; that's why some linkintegrity tests are failing. Actually they both need to be used. And that's just a guess -- I haven't actually looked at this yet. It doesn't look like there's any way to override OFS traversal using a component (other than a view of course). Perhaps we should just be using the existing custom __getitem__ that's already in BaseObject/BaseFolder instead of traversal magic. That seems like a decent idea to me, given that we need this to work for publish traversal, OFS traversal, and path expressions in order to avoid regressions. 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). 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... 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 :) cheers, 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/ PGP.sig 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
Re: (Was Re: [Framework-Team] Minutes: 8 August 2009)
On Aug 6, 2009, at 2:42 PM, Andreas Zeidler wrote: On Aug 6, 2009, at 6:30 AM, David Glick wrote: On Aug 5, 2009, at 1:45 PM, Alec Mitchell wrote: On Wed, Aug 5, 2009 at 1:18 PM, David Glickdavidgl...@onenw.org wrote: * IPublishTraverse is used where ITraverse should be; that's why some linkintegrity tests are failing. Actually they both need to be used. And that's just a guess -- I haven't actually looked at this yet. It doesn't look like there's any way to override OFS traversal using a component (other than a view of course). Perhaps we should just be using the existing custom __getitem__ that's already in BaseObject/BaseFolder instead of traversal magic. That seems like a decent idea to me, given that we need this to work for publish traversal, OFS traversal, and path expressions in order to avoid regressions. 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 [...] 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? cheers, 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/ PGP.sig 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
Re: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009)
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. David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@onenw.org work: (206) 286-1235 x32 mobile: (206) 679-3833 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009)
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/ PGP.sig 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
Re: (Was Re: [Framework-Team] Minutes: 8 August 2009)
On Aug 5, 2009, at 1:45 PM, Alec Mitchell wrote: On Wed, Aug 5, 2009 at 1:18 PM, David Glickdavidgl...@onenw.org wrote: * IPublishTraverse is used where ITraverse should be; that's why some linkintegrity tests are failing. Actually they both need to be used. And that's just a guess -- I haven't actually looked at this yet. It doesn't look like there's any way to override OFS traversal using a component (other than a view of course). Perhaps we should just be using the existing custom __getitem__ that's already in BaseObject/BaseFolder instead of traversal magic. That seems like a decent idea to me, given that we need this to work for publish traversal, OFS traversal, and path expressions in order to avoid regressions. 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? 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). David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@onenw.org work: (206) 286-1235 x32 mobile: (206) 679-3833 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
