[Zope-PTK] PTK II

[Phillip J. Eby]

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...

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 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.

At 10:41 AM 7/31/00 -0400, Shane Hathaway wrote:
>
>The problem is simple: how do you keep the tool from being overridden? 
>Say we create a tool called "membership" at the base of the portal, and
>set up all DTML to route membership requests through that object (i.e.
>"membership.getAuthenticatedMember()")  What if someone accidentally
>creates an object somewhere in the portal called "membership"?  What if
>it's created deliberately?  DTML that was looking for the membership
>tool would access something else entirely.  There's also the problem of
>DTML keyword arguments, which override *anything*. (Consider <dtml-var
>expr="logged_in(_.None, _, getPortal=securityHack)"> ... grumble ...)
>
>There are several possible solutions, but they're all unreliable.
>
>1) The way it's currently solved is through the getPortal() method. 
>Every type of content has this method.  Zope's _checkId() method
>doesn't allow anyone to create an object with an ID that's being used
>by a method of the container, so for the most part this works.  It's
>difficult to create a getPortal object by accident, but not impossible
>to create deliberately.
>
>2) Watch the id's that users enter and disallow a specific set of
>id's.  The fix would not apply to the management interface and would
>require a registration system where tools register with the portal. And
>we'd still need the getPortal() method, making this solution
>meaningless (since we could just call "getPortal().membership".)
>
>3) Modify Zope's _checkId() method so that if an object by the same ID
>already exists in the hierarchy and has the "__singleton__" class
>attribute set, the addition is disallowed.  This might solve the
>problem for more than just PTK.  But it would have to go through the
>fishbowl.
>
>In addition to any of the above, it may make sense to also provide a
>new checkbox for DTML methods that causes them to ignore keyword
>arguments.  This probably belongs in the fishbowl also.