[Zope-dev] Re: State of the philikon-aq-and-__parent__ branch

Hanno Schlichting plone at hannosch.info
Sun Jun 24 20:25:24 EDT 2007


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



More information about the Zope-Dev mailing list