[Zope-dev] 'transparent' proxying to a method not in your nam
espace?
sean.upton@uniontrib.com
sean.upton@uniontrib.com
Wed, 08 Aug 2001 11:48:12 -0700
Were you able to call a method within a namespace for which it did not
actually exist in this case? If so, that's sort of what I am after, except
instead of user directory service, I'm thinking more along the line of a
method directory service for said lookups and method calling.
More specifically, I got this _really_ crazy idea into my head... ever
since Jim's OSCON Components BOF, my brain has been trying to wrap around
high-level use-cases of how it could be useful. That got me thinking a lot
about a folder that I have that is bloated with all sorts of stuff;
thousands of objects (mostly content), with dozens in the main folder -
including code, presentation, sql, and content objects all over the place,
and no matter how well I try to organize them, it still seems really messy -
but it wouldn't be in service-oriented world.
My interest is motivated by some frustrations with Transparent Folders.
What I'm actually thinking of, I guess, is a little bit more ambitious: a
lightweight 'interim' component/services type of system with a method
directory/catalog service; let me explain:
I have a folder - let's call it 'Content' - and it doesn't have a method I
need to do something, for example, like an automation task set up in a TTW
python script. In my ideal vision here, the method can be stuffed off in a
central 'Code' folder located somewhere else in the odb hierarchy; My
'Content' folder needs a method called 'purgeExpiredContent' as an
automation task. 'purgeExpiredContent' exists in the 'Code' folder;
'Content' doesn't have anything called 'purgeExpiredContent' but 'Content'
is not a normal folder - it is a SuperMagicalGeniusFolder(TM) (perhaps there
is a better name); if the folder had a dialog with itself, this is the
conversation it would have:
....................
"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..."
....................
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.
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...
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 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...
Sean
-----Original Message-----
From: Dyon Balding [mailto:dyon.balding@monster.com]
Sent: Wednesday, August 08, 2001 10:15 AM
To: sean.upton@uniontrib.com
Cc: zope-dev@zope.org
Subject: Re: [Zope-dev] 'transparent' proxying to a method not in your
namespace?
Sean,
I think I understand what you're trying to do; if so, I've done
something similar. What I had was a list of staff members pulled from
LDAP, and a folder containing objects representing some of those staff
members (those who had customized their information). The URLs from the
staff list page were all the same, ie blah/staff/name or similar. I then
had a site access_rule that grabbed and rendered the customized object if it
existed, or retrieved some generic information from LDAP and rendered it
if it didn't.
I think that's approximately what you're trying to do? If the above
method sounds plausible I can give you a copy of my code if it's any help.
-d
On Wed, Aug 08, 2001 at 09:22:51AM -0700, sean.upton@uniontrib.com wrote:
> Problem: I have a custom folder type, and I want to hijack unsuccessful
> method lookups in its namespace and have them transparently proxy to code
in
> another folder...
>
> I have a Python product class that uses Folder as it's base; it's
cluttered
> with code objects, and I don't want to have to use Transparent Folders,
> which seem to break one thing or another. I'm also looking for (perhaps)
> something as an application-specific alternative/addition to acquisition
as
> a namespace traversal mechanism.
>
> I had this idea of storing my various methods in a 'ProjectCode' folder in
> the Zope root, and having my 'Folder' evaluate its own namespace looking
for
> a method; if it doesn't exist, before the Zope looks in the acquisition
> parent(s), the 'Folder' looks in the namespace for the 'ProjectCode' (or
> some other folder name) folder in the root to find the method, and run it
> within the 'Folder' namespace.
>
> I'm sort of ignorant as to where to start looking if I wanted to do this,
> but I'm willing to investigate and figure out how to code it if it's
> something that can be done within my product code or in a hotfix, and
> doesn't require a patch the size of Texas...
>
> Thoughts?
>
> Sean
>
> =========================
> Sean Upton
> Senior Programmer/Analyst
> SignOnSanDiego.com
> The San Diego Union-Tribune
> 619.718.5241
> sean.upton@uniontrib.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 )
--
| Dyon Balding . Software Engineer . HiringTools.Monster.com
| dyon@hiringtools.com . +1 415 288 3375