[Zope-PTK] PTK II
Mon, 31 Jul 2000 12:56:25 -0400
"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.
> 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
Three states would be available (should all three states have names?):
__replaceable__ = 0 # current
__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.