[Zope3-dev] traversal, services, and namespaces

Gary Poster garyposter@earthlink.net
Wed, 15 May 2002 10:15:51 -0400


ah-ha.

uh.

it does what I wanted already.

Except for the parts I had messed up before, when trying to build out some of 
the functionality in some previous check-ins.

So, I'll fix my own errors and all should be well.  And don't bother thinking 
about my email further, if you had spent any time on it.

Gary



On Tuesday 14 May 2002 06:33 pm, Gary Poster wrote:
> So that we can get a usable absolute path to services and other items that
> are found in non-content namespaces, I'm fairly sure that we'll have to
> include the namespace in the wrapper dictionary, perhaps in its name
> attribute.  I.e., hypothetically (in
> Zope.App.ZopePublication.PublicationTraverse),
>
> 	return ContextWrapper(ob, parent, name=name)
>
> would have to be setting, for instance, either name="Services;etc" or
> name="Services;ns=etc" whenever the currently found object is a service
> manager.  Otherwise, if we merely do what we're doing now for the various
> namespaces (name="Services") our traversal adapters will give us a path
> that will try to find the "Services" name in the content namespace, and
> fail.
>
> (one use case in which we want a usable path to a service: path, or soft,
> subscribers to an event service)
>
> So it seems pretty clear to me that, at least for services, the name stored
> in the wrapper should include the namespace.
>
> 1) does anybody disagree?
> 2) for instance, do you agree with the need but feel that this would be
> better accomplished by including the namespace as another member of the
> context wrapper--"ns='etc'" for instance?  Then the traversal adapter will
> have to take this into account when assembling paths.
> 3) don't we need this for the "acquire" namespace too?
> 4) any other namespaces needed to create a robust absolute path?
> 5) might usable absolute paths require other path parameters to accurately
> return the desired object?  If so, this may get messy.  Can we YAGNI this
> and explicitly state that parameters cannot be used in this manner?  But if
> so, what exactly are parameters good for, anyway?  Should these also be
> placed separately in the context wrapper?  Currently the code is throwing
> away all unused parameters, although it appears that someone wanted them to
> be stored somewhere at one time...
>
> Gary
>
>
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev