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

[sean.upton@uniontrib.com]

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 )