[Framework-Team] Re: [Plone 4] Zope 2.12 status

David Glick davidglick at onenw.org
Wed Jul 1 19:22:57 UTC 2009

On Jul 1, 2009, at 12:13 PM, Hanno Schlichting wrote:
> As a general comment, it might be that selectively trying to backport
> my stuff won't necessarily be the quickest way forward anymore.
> Especially ones you hit stuff I did later on, it all moves to
> dependency reduction and speedups, which aren't required to get the
> stuff running on Zope 2.12. Working from the unittests / TTW-testing
> until stuff works is another way to do it.

Yep, I've already shifted mostly into this mode.

>> - sort out PloneFolder situation (it can probably go but I need to  
>> confirm
>> that)
> I think I responded to that already... it can go, as its only used
> indirectly by the temporary folder from portal factory and some tests.
> Or you let it stay. It doesn't matter much, as it's so little.

Yeah, you did, I just haven't had a chance to deal with it yet.

>> - sort out actions API change (Hanno changed the way you fetch an  
>> action
>> category on trunk; I haven't had a chance to look closely and  
>> figure out
>> what the risks are yet)
> I'd stay away from those. There's quite a number of evolutionary
> changes made over time. The end result as seen today on trunk is
> nowhere near what I'd consider to be finished. This is really a
> separate change. Even in its minimal version it requires
> backwards-incompatible API changes, that currently aren't documented.
> It should also be a more conscious choice to break API compatibility
> with the CMF actions API, which I did here implicitly.

Yep. It's on the todo list because I merged some of this before I  
understood its implications, and I have to take it back out.

>> - sort out GRUF/PAS changes (on trunk Hanno removed the GRUF  
>> dependency and
>> moved the tools to PlonePAS...I need to figure out how risky this is)
> Merging all the functionality into one place and getting rid of the
> GRUF package should be fairly save. It just needs BBB imports in the
> old locations in CMFPlone, so that persistent versions continue to
> work. We could either live with those BBB imports in place or write a
> migration, which updates the persistent stuff to use the new canonical
> import location. Or you don't touch any of this, as it's not strictly
> required to get stuff running.

Yep. Thanks for this info.

>> - sort out use of Globals and other deprecation warnings
> That should all be fairly simple and just time consuming. It's a job
> for grep after InitializeClass for the most part.


>> - sort out javascript stuff (on trunk Martijn and Roel moved this to
>> plone.app.javascript, I need to look more closely)
> The p.a.javascript stuff also includes rewriting some of that JS to
> jQuery and making a number of other changes. I'd just ignore all of
> that and continue to keep the JS files as found in Plone 3.x.

Yeah, that seems like the safe approach. We should probably at least  
update to the latest jquery though.

>> - sort out image traversal stuff / linkintegrity (image scales are  
>> now found
>> via an IPublishTraverse adapter rather than __bobo_traverse__,  
>> which doesn't
>> work during non-publish traversal, so linkintegrity fails to detect  
>> that
>> images are linked in a document)
> Huh? I thought that change was only part of Archetypes trunk and not
> in the scope of Plone 4.

I haven't given a lot of attention to Archetypes yet.  We can (and  
probably should) exclude that change.

David Glick
Web Developer

New tools and strategies for engaging people in protecting the  

davidglick at onenw.org
work: (206) 286-1235 x32
mobile: (206) 679-3833

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement

More information about the Framework-Team mailing list