[Zope-dev] 'transparent' proxying to a method not in your namespace?

[Casey Duncan]

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