[Zope-PTK] PTK II

[Shane Hathaway]

"Phillip J. Eby" wrote:
> 
> How about this?  Define _getPortal() on the Portal, and then have a
> getPortal() method on portal content objects that acquires and calls
> _getPortal()?.  No muss, no fuss (i.e. no changes to anything but the PTK).
>  :)  Granted that you still need getPortal...

Good suggestion but it doesn't overcome the fundamental problem. 
However...

> The other alternative would be to take our __replaceable__ property that we
> talked about for overriding class methods in instances, and have another
> value of it that meant "don't override even in subobjects".  Singletons
> could then set that value, so that once you created such a singleton, you
> couldn't block it from being acquired in any sub-object.

This sounds like a great idea, Phillip.  Just a few new lines of code
and we instantly get a refinement of the Zope object model.  That's
cool.

Three states would be available (should all three states have names?):

__replaceable__ = 0                                   # current
behavior
__replaceable__ = 1                                   # instance config
__replaceable__ = ObjectManager.NO_SUBOBJECT_OVERRIDE # singleton

> This still doesn't fix keyword overrides, I admit.  But that issue could be
> dealt with by giving the "_" object a "self" or "this" attribute that
> refers to the currently executing method, thus giving a known starting
> point.  A tool would then always be accessible as "_.self.toolname".  The
> addition of a reference to the current object would be generally useful and
> also not break anything.

There already is a _.this, it's set to the DTMLMethod or Document that
first created the namespace.  But we could add a _.self.  That would
solve the keyword problem.  One line of code.  One word: wow.

I'll see what we can do about making this happen right away, unless
anyone has any objections.  Thank you, Phillip.

Shane