I think you maybe misunderstand the traversal.
suppose you have a resource tree like this:
root
|-- foo-1
|-- bar-1
|-- bar-2
|-- foo-2
|-- bar-3
|-- bar-4
All the resouce you have must be dict like. It means that you should have
methods like __getitme__ , __setitme__,et. In the follow example, I assume
all the class have proper __getitme__ method.
Then we must have a root class and root factory,the root factory return a
instance of root class.maybe like this:
class Root():
def __init__(self,name = "", parent = ""):
self.__name__ = name
self.__parent__ = parent
def __getitem__(self,key):
"return something base the key"
def rootFactory():
return Root() #the root's name and parent must to be null
Then we'll define the Foo and Bar class:
class Foo():
def __init__(self,name,parent):
self.__name__ = name
self.__parent__=parent
class Bar():
def __init__(self,name,parent):
self.__name__ = name
self.__parent__=parent
then you can create any nodes at any palces.like that:
foo-1 = Foo(name = "foo-1",parent = root)
foo-2 = Foo(name = "foo-2",parent = root)
bar-1 = Bar(name = "bar-1",parent = foo-1)
bar-2 = Bar(name = "bar-2",parent = foo-1)
bar-1 = Bar(name = "bar-3",parent = foo-2)
bar-2 = Bar(name = "bar-4",parent = foo-2)
at this piont, request.resource_url(baz-4) will return /foo-2/bar-4
在 2011年11月11日星期五UTC+8下午11时51分40秒，Norman Ives写道：
> Hi list
> This message is about using pyramid, rather than about its development. I
> hope that's okay.
> I'm new to the traversal mechanism for managing resources and views. I
> really like the idea of a resource tree. I thought I'd write a quick note
> on how I'm using it in the hope of drawing comments and comparisons.
> Particularly, I'll describe what I've done to make any instance of a tree
> resource location-aware, even if it wasn't reached by traversal.
> Using traversal with a resource tree that looks like /foo-1/bar-2/baz-3 I
> find it very convenient to build URLs using the request.resource_url
> interface. I often want to build lists of URLs like this:
> for baz in bar_instance.bazzes:
> request.resource_url(baz)
> I don't want to say request.resource_url(bar_instance, 'baz-%s' % baz.id)
> because I don't want to spread around responsibility for representing the
> resource tree and because, in the real case, the required call to
> resource_url would be even uglier.
> For all of my tree resources there is a natural parent (and it makes sense
> to assume that if they exist then they can be located on the resource
> graph; I never have to deal with resources that are disconnected in
> principle) so I can say, for example
> class Baz:
> @property
> def __name__(self):
> return 'baz-%s' % self.id
> @property
> def __parent__(self):
> return self.bar
> which neatly enforces the structure of the resource graph in general. The
> trouble is with the first layer of children in the tree. They need to point
> at the application root.
> If I have an instance of one of these first layer children that wasn't
> loaded by traversal, then the only way I can think of to get at the
> application root directly is via pyramid.threadlocal.get_current_request.
> That would make my domain models dependent on pyramid which doesn't seem
> very natural. Conceptually, I suppose the resources should sort out their
> own tree root anyway, rather than trying to look somewhere else for it. And
> so my resource package grew two new functions, set_tree_root and
> get_tree_root.
> The application root factory contains
> class AppRoot:
> def __init__(self, request):
> set_tree_root(self)
> and top-level resources contain
> class Foo:
> @property
> def __parent__(self):
> return get_tree_root()
> Behind the scenes, those two functions modify and access a thread-local
> variable.
> Does this sound broadly reasonable? Am I going to run into problems later?
> How do you usually implement and use the resource tree?
> Regards
> Norman
