State of the philikon-aq-and-__parent__ branch
Hi, as some of you may have noticed I worked a bit more on philikon's branch which makes Acquisition and in return the Zope2 security machinery aware of __parent__ pointers. The branch can be found here: svn+ssh://svn.zope.org/repos/main/Zope/branches/philikon-aq-and-__parent__ The current state is that there's only one test failure left in Five which concerns the Zope2 version of the TAL provider expression and the viewlet machinery. It is a bad combination of lots of manual AQ-wrapping and irritating __parent__ pointers and can probably be fixed by removing most of the manual wrapping. As I won't have much time to work on this anymore, I would encourage all of you to take a look at the branch and help in finishing it. What's left to do is the fun part of ripping apart Five and removing as much Acquisition mix-in classes from it as possible. After that many Five constructs should actually be identical to their Zope3 counterparts and thus can be deprecated. Anyone feels like eliminating some code? Hanno
Hanno Schlichting wrote:
Hi,
as some of you may have noticed I worked a bit more on philikon's branch which makes Acquisition and in return the Zope2 security machinery aware of __parent__ pointers.
The branch can be found here: svn+ssh://svn.zope.org/repos/main/Zope/branches/philikon-aq-and-__parent__
The current state is that there's only one test failure left in Five which concerns the Zope2 version of the TAL provider expression and the viewlet machinery. It is a bad combination of lots of manual AQ-wrapping and irritating __parent__ pointers and can probably be fixed by removing most of the manual wrapping.
As I won't have much time to work on this anymore, I would encourage all of you to take a look at the branch and help in finishing it.
What's left to do is the fun part of ripping apart Five and removing as much Acquisition mix-in classes from it as possible. After that many Five constructs should actually be identical to their Zope3 counterparts and thus can be deprecated.
Anyone feels like eliminating some code?
Wohoo! You rock, Hanno! :) Do the Plone tests all run with this branch? There's a fair amount of silly wrapping and acrobatics there too, so it's probably a good test case. Maybe we should've just made this your SoC project. Too late now! :) -- Acquisition is a jealous mistress
Hi. Martin Aspeli wrote:
Hanno Schlichting wrote:
as some of you may have noticed I worked a bit more on philikon's branch which makes Acquisition and in return the Zope2 security machinery aware of __parent__ pointers.
The current state is that there's only one test failure left in Five which concerns the Zope2 version of the TAL provider expression and the viewlet machinery. It is a bad combination of lots of manual AQ-wrapping and irritating __parent__ pointers and can probably be fixed by removing most of the manual wrapping.
Do the Plone tests all run with this branch? There's a fair amount of silly wrapping and acrobatics there too, so it's probably a good test case.
The branch exist for quite a long time and hasn't been updated with any changes from Zope trunk. This causes Plone tests to produce lots of ImportErrors (for example the requestmethod decorator, pt unicode conflict resolver) so I cannot run the tests easily.
Maybe we should've just made this your SoC project. Too late now! :)
My real SoC project is the reason why I cannot spent more time on this AQ topic ;) Hanno
Hanno Schlichting wrote:
as some of you may have noticed I worked a bit more on philikon's branch which makes Acquisition and in return the Zope2 security machinery aware of __parent__ pointers.
Yay, thanks Hanno!
As I won't have much time to work on this anymore, I would encourage all of you to take a look at the branch and help in finishing it.
I would like to review this branch myself. Actually, I want to branch the current Zope 2 trunk again and reapply each change, mostly because I stupidly changed the formatting of the Acquisition C code which was completely unnecessary. Also, I want to get a better understanding of all the changes that have now accumulated over the past months. I hope to be able to do this soonish. Once this is done, we can also test CMF, Plone, ... on that branch because it's much newer. In order to be able to get a good comparison, they should run fine on a Zope 2 trunk in the first place which might take some time to sort out anyway.
What's left to do is the fun part of ripping apart Five and removing as much Acquisition mix-in classes from it as possible. After that many Five constructs should actually be identical to their Zope3 counterparts and thus can be deprecated.
... or just left around indefinitely and simply discouraged. It's not like they're going to hurt anybody. Also, it might be wise to leave some of them around for a while. I bet there's tons of code out there that relies on being able to call __of__ on Five browser views or relies on their ExtensionClass semantics. -- http://worldcookery.com -- Professional Zope documentation and training
Philipp von Weitershausen wrote:
Hanno Schlichting wrote:
as some of you may have noticed I worked a bit more on philikon's branch which makes Acquisition and in return the Zope2 security machinery aware of __parent__ pointers.
Yay, thanks Hanno!
As I won't have much time to work on this anymore, I would encourage all of you to take a look at the branch and help in finishing it.
I would like to review this branch myself. Actually, I want to branch the current Zope 2 trunk again and reapply each change, mostly because I stupidly changed the formatting of the Acquisition C code which was completely unnecessary. Also, I want to get a better understanding of all the changes that have now accumulated over the past months.
I hope to be able to do this soonish. Once this is done, we can also test CMF, Plone, ... on that branch because it's much newer. In order to be able to get a good comparison, they should run fine on a Zope 2 trunk in the first place which might take some time to sort out anyway.
That's awesome news. I'll probably try to find some time to test this besides my limited time ;)
What's left to do is the fun part of ripping apart Five and removing as much Acquisition mix-in classes from it as possible. After that many Five constructs should actually be identical to their Zope3 counterparts and thus can be deprecated.
.... or just left around indefinitely and simply discouraged. It's not like they're going to hurt anybody. Also, it might be wise to leave some of them around for a while. I bet there's tons of code out there that relies on being able to call __of__ on Five browser views or relies on their ExtensionClass semantics.
Well probably you are right and we can just leave most of the code in place and deprecate it. The only thing I would really like to see fixed is the current behavior of Five's BrowserView which wraps self.context in the view itself resulting in a pretty broken Acquistion chain for the context. Having to do "context = aq_inner(self.context)" every time one accesses the context in a view is just annoying. Hanno
participants (3)
-
Hanno Schlichting -
Martin Aspeli -
Philipp von Weitershausen