The way you frame it makes a lot of sense; if one was to name this sort of beast it might be called 'worm-hole folders' or something - that is, there is a globally available namespace that can be obtained and pushed onto the stack below the containerment stack... I'm definitely tempted to try creating something like this as an interim solution; it would be much more graceful than using Transparent Folders, since re-use of code would be more encouraged; I suppose that one would just hardcode the path (somehow) to the namespace you want to use for the code into a 'worm-hole folder' property. I'm still thinking that in the longer-term future there are cases where full-fledged lookups using something like Catalog should be used (and, of course, cached) from a more full-featured directory. I guess the use-case I am thinking of is partially similar to: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FindOutIfAF eatureIsAvailableAtRuntime More specifically, I wouldn't mind being able to use a code folder that kept resource metadata about methods and a method directory service catalog that was able to extract that for publishing in web-services discovery (via WSDL) processes, as well as to internal content objects that asserted a particular interface, which is a bit more demanding that simply shifting a namespace onto the stack... I'm sure that if I can get something like the 'worm-hole folders' solution put together, that later deciding which namespace gets pushed onto the stack based-upon a (potentially cached) lookup through a method catalog should be possible. In that case, only the namespace containing the method that best-serves the use-case (as queried) or content object interface is going to be shifted onto the stack... Sean -----Original Message----- From: Casey Duncan [mailto:cduncan@kaivo.com] Sent: Thursday, August 09, 2001 12:55 PM To: sean.upton@uniontrib.com Cc: dyon.balding@monster.com; zope-dev@zope.org Subject: Re: [Zope-dev] 'transparent' proxying to a method not in your namespace? sean.upton@uniontrib.com wrote:

[snip]

.................... "Someone just asked me to run a method called purgeExpiredContent. Do I have a method called that in my namespace?" "No." "Ok, I need to find it elsewhere; before I look in the namespace stack using acquisition, I am going to look up in a directory service if the method exists elsewhere. Does the Method Directory Service indicate it knows where this method lives?" "I just queried it, and it does know where this method lives; the path:..." "Ok, I got that path... " "I found the method; I'm going to run it within my ('Content') namespace." "Ok, I'm done..." ....................

So from what I read here, the namespace of this folder should be just after the namespace of the object, but before the general containment namespace stack, right?

In this case, the method 'purgeExpiredContent' is more of a service to the 'Content' folder. The 'Method Directory Service' was likely a ZCatalog-derived lookup 'service object' in the Zope root; it's query

result

contained the path needed for 'Content' to obtain and run the method from wherever it lived (in this case, a folder called 'Code' in the Zope root, but using a method directory service, it really could live anywhere). The 'Content' folder had the smarts to intelligently look in the 'method directory' for methods it didn't have before it traversed its acquisition parents looking for it.

I would think the way to handle this would be to push this 'method directory service' namespace into the namespace object multi-mapping right before the object was executed. I don't think this would require too much in the way of coding, and would still rely on the built-in acquisition framework. It would be like automatically wrapping a with statement around the call.

It should be said that this feature should be provided via acquisition to contained objects below this SuperMagicalGeniusFolder(TM) called 'Content' and would use the namespace of the object it is called upon.

This would make partitioning code, content, and presentation a lot easier. A method directory service and a smart folder like that could even use (optionally, in a componentized universe) as a 'method directory service' query parameter the interface asserted by the object trying to get the method as a means to determine if an method actually can be obtained; the catalog would return no resulting method even if it existed, but didn't

work

with the correct interface...

You could create a simple subclass of folder that registers itself into this "MDS" namespace when it is created. Then a hotfix could push in this namespace at the appropriate point in the object publication process.

I know I should just be patient and wait for component architecture

('cause

yes, I now really see a need for it), but this idea is just stuck in my head, and I can't get it out cause it seems so useful... and it seems to me that one could use a modified ZCatalog as a good directory service for method lookups.

I think a ZCatalog would introduce way too much overhead. This lookup would happen (though not usually successfuly) with nearly every web request. For instance, any call to standard_html_header would require a lookup in the MDS, which would likely fail. With standard acquisition, the additional overhead should be largely unnoticable.

I guess the complicated question (for me, at least) is whether or not the process of acquisition could be interrupted and/or preempted for an alternate traversal means for obtaining methods either inside my Product code or in a hotfix product. The concept of method lookup doesn't seem daunting, but making it execute transparently does. I would hope

something

like this would be possible without modifications to the Zope core...

I think you could still use standard acquisition, just modify the namespace stack so that MDS folders are near the top all the time (or whenever you want them there).

Sean

-- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------> _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )