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: [Framework-Team] Minutes: 8 August 2009
On Aug 5, 2009, at 1:00 PM, Erik Rose wrote: Python 2.6, Zope 2.12 (https://dev.plone.org/plone/ticket/8808): * David ported the migration procedure to GS and moved it into plone.app.upgrade. Ran a migration from a stock Plone 2.5 to 4.0, and it seemed to work, though he welcomes more thorough testing. Actually Hanno did the work here, and I just copied it :) * 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. 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: [Framework-Team] Minutes: 8 August 2009
On Wed, Aug 5, 2009 at 1:18 PM, David Glickdavidgl...@onenw.org wrote: On Aug 5, 2009, at 1:00 PM, Erik Rose wrote: Python 2.6, Zope 2.12 (https://dev.plone.org/plone/ticket/8808): * David ported the migration procedure to GS and moved it into plone.app.upgrade. Ran a migration from a stock Plone 2.5 to 4.0, and it seemed to work, though he welcomes more thorough testing. Actually Hanno did the work here, and I just copied it :) * 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. Alec ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Minutes: 8 August 2009
On Wed, Aug 5, 2009 at 10:00 PM, Erik Rosepsuc...@grinchcentral.com wrote: * All the globalization in templates is gone now, and Plone's templates have been updated to not use it. This originated in the 5.x branch as a speed optimization, but does it deliver? It's going to break a lot of products. MatthewWilkes will talk to Hanno about this and see if it really did help performance. The FWT is concerned about breaking every product if it turns our we're just replacing one very slow thing with many less-slow things. This change is not only and maybe not even primarily a speed optimization. When running performance tests against current Plone 4 for typical full-fledged pages like a document view, edit screens or folder contents views, there is hardly any performance difference between Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate performance gain for those kind of pages, but neither is there any increased cost. One thing where you should be able to measure a significant difference is on classic portlets. These used to set up all the globalize stuff again for the separate expression context of the classic template, making them quite a bit slower. Executing the globalize hack twice or even many times was certainly quite a bit of a difference. The reasons why I'm very much in favor of removing the globalize hack are different ones: Obviously the way it is done is an utter hack. Walking up stack frames to inject things into a higher global scope is very evil. Second the globalized names are today a random set of shortcuts, which have little to do with the typical need inside templates. They started out a point where access to a set of tools was essentially the whole Plone API, but this isn't the case anymore. Now they just make it harder to understand template code as there is no way to find the actual code path from for example the syntool name inside a template to the actual implementation. They obscure templates for little to no benefit, as most often the real call is a one-liner itself and context/portal_syndication gives a much better searchable term. Another point is that they make templates rely on execution order of the whole macros system. They only work when called after the globalize hack has been executed but not in isolation. This also leads to problems when trying to move templates into more reusable packages as it becomes very hard to see the actual dependencies of the template. What looks like locally defined shortcuts turn out to be oh and btw. I need those other ten packages-type dependencies. It would have been much harder to understand and disentangle dependencies between packages on trunk, if those hacked in names still would have been in place. If we want to make things optional to get people a more speedy and less memory hungry Plone, having a central place that binds them all doesn't work. And last removing these calls from a centralized place makes both profiling of what actually contributes to the slowness of Plone much easier and allows for easier deprecation of some of the so far globalized names. For example many of the actual performance improvements on trunk result from changes to the way actions are looked up. To make these work, all of the actions, keyed_actions, user_actions, workflow_actions, folder_actions, global_actions names of todays globalize thing need to be deprecated and replaced. Instead of always having these defined everywhere, they need to be turned into a pattern where only the viewlet / macro that actually shows the particular action category also calls and evaluates those actions. For example hiding the personal bar in the UI today doesn't make a difference since all the actions in that category are still evaluated and their conditions checked. Even though nobody will ever show any of them. Maybe I forgot other reasons why this particular hack is considered one ;-) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Minutes: 8 August 2009
I concur that the globalize stuff is a serious hack and should be removed at some point. However, I don't think 4.0 is the right time to remove it considering the huge impact it will have on 3rd-party products. If removing it doesn't result in a significant performance improvement (and apparently it does not), then I'd suggest we continue to live with it until the break-everything 5.0 release. We didn't have a PLIP for this and it would be a major disruption for 3rd party developers and integrators. Perhaps we could find some clever way to deprecate access to the globalized attributes (e.g. make them all lazy lookups and issue a warning on first access)? Alec On Wed, Aug 5, 2009 at 2:15 PM, Hanno Schlichtingha...@hannosch.eu wrote: On Wed, Aug 5, 2009 at 10:00 PM, Erik Rosepsuc...@grinchcentral.com wrote: * All the globalization in templates is gone now, and Plone's templates have been updated to not use it. This originated in the 5.x branch as a speed optimization, but does it deliver? It's going to break a lot of products. MatthewWilkes will talk to Hanno about this and see if it really did help performance. The FWT is concerned about breaking every product if it turns our we're just replacing one very slow thing with many less-slow things. This change is not only and maybe not even primarily a speed optimization. When running performance tests against current Plone 4 for typical full-fledged pages like a document view, edit screens or folder contents views, there is hardly any performance difference between Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate performance gain for those kind of pages, but neither is there any increased cost. One thing where you should be able to measure a significant difference is on classic portlets. These used to set up all the globalize stuff again for the separate expression context of the classic template, making them quite a bit slower. Executing the globalize hack twice or even many times was certainly quite a bit of a difference. The reasons why I'm very much in favor of removing the globalize hack are different ones: Obviously the way it is done is an utter hack. Walking up stack frames to inject things into a higher global scope is very evil. Second the globalized names are today a random set of shortcuts, which have little to do with the typical need inside templates. They started out a point where access to a set of tools was essentially the whole Plone API, but this isn't the case anymore. Now they just make it harder to understand template code as there is no way to find the actual code path from for example the syntool name inside a template to the actual implementation. They obscure templates for little to no benefit, as most often the real call is a one-liner itself and context/portal_syndication gives a much better searchable term. Another point is that they make templates rely on execution order of the whole macros system. They only work when called after the globalize hack has been executed but not in isolation. This also leads to problems when trying to move templates into more reusable packages as it becomes very hard to see the actual dependencies of the template. What looks like locally defined shortcuts turn out to be oh and btw. I need those other ten packages-type dependencies. It would have been much harder to understand and disentangle dependencies between packages on trunk, if those hacked in names still would have been in place. If we want to make things optional to get people a more speedy and less memory hungry Plone, having a central place that binds them all doesn't work. And last removing these calls from a centralized place makes both profiling of what actually contributes to the slowness of Plone much easier and allows for easier deprecation of some of the so far globalized names. For example many of the actual performance improvements on trunk result from changes to the way actions are looked up. To make these work, all of the actions, keyed_actions, user_actions, workflow_actions, folder_actions, global_actions names of todays globalize thing need to be deprecated and replaced. Instead of always having these defined everywhere, they need to be turned into a pattern where only the viewlet / macro that actually shows the particular action category also calls and evaluates those actions. For example hiding the personal bar in the UI today doesn't make a difference since all the actions in that category are still evaluated and their conditions checked. Even though nobody will ever show any of them. Maybe I forgot other reasons why this particular hack is considered one ;-) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list
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
