/me dons his "traversal explainer" cape and mask...
first, and foremost, i don't think you actually need or want traversal here.
you say you read the "traversal" and "resources" chapters of the docs, but did
you read the "much ado about traversal" piece (http://tinyurl.com/4exxjvw)?
especially the "use cases" section, where it describes the cases where
traversal is a better choice than URL matching. your use case meets none of
those criteria, AFAICT, so you probably don't want to use traversal at all.
i'm pretty sure you CAN still use config.scan to register your views even w/o
traversal, so i'm not entirely sure what the problem is there.
but, just for the fun of it, let's say traversal was a good idea. what are
you doing wrong? there are a few things that seem a bit wonky in the code
(e.g. the fact that your resource class inherits from dict but then doesn't
act like a dict, delegating to a contained dictionary attribute instead), but
i'll ignore those for now. the main problem seems to be that you're trying to
use specific instances as your "context", when really context is better suited
to using types.
something like this is probably closer to what you want (totally untested, use
at your own risk, this code may steal your car and eat your cookies, etc.):
class Resource(object):
def __init__(self, name=None, parent=None):
self.__name__ = name
self.__parent__ = parent
self.children = {}
def add_child(self, name, klass=None, **kw):
if klass is None:
child = Resource(name, self)
else:
child = klass(name, self, **kw)
self.children[name] = child
def __getitem__(self, name):
return self.children[name]
class Task(Resource):
pass
then you'll need to instantiate some of these things:
root = Resource('root')
root.add_child('some_task', Task)
root.add_child('another_task', Task)
now you can register a view on Task objects like this:
@view_config(name="method", context=Task)
def task_method(request):
task = request.context
... do something w/ your task object ...
return Response(...)
if this is all wired up correctly then the following paths should resolve to
your view:
/some_task/method
/another_task/method
now it might be possible to achieve the same thing by using a specific
instance as your context rather than a class... the view config docs don't say
anything about that, though, and i've never done it; i'd find it a bit confusing.
hope this helps,
-r
On 06/14/2011 01:58 PM, toudi wrote:
hello.
before i begin i would like to say, that i have read both 'Traversal'
and 'Resources' chapters from pyramid docs. I also read this thread ->
http://groups.google.com/group/pylons-devel/browse_thread/thread/a8d4cc7e8d0c9855
which is a similar problem i have, but i still cannot wrap my mind
around traversal. However, i think it's the best approach for me,
because of it's config.scan() capabilities. I also have a background
in pylons, which i was using without any problems.
So - to keep my long story short, i am trying to implement a fairly
simplistic application (task / bugtracker) in order to learn pyramid.
Here are the models:
User - a developer
Task - a Bug, that can have one developer and many comments.
Comment - a Task comment.
i have named my project 'flyswatter', therefore:
#flyswatter/__init__.py
...
config = Configurator(settings=settings)
config.add_static_view('static', 'flyswatter:static')
config.scan(".views")
...
#flyswatter/resources.py
class Resource(dict, object):
def __init__(self, name = None, parent = None):
self.__name__ = name
self.__parent__ = parent
self.children = {}
def add_child(self, name):
self.children[name] = Resource(name = name, parent = self)
def __getitem__(self, name):
return self.children.get(name)
root = Resource()
now - onto my problem. I would like to use config.scan() and traversal
in order to map url's to the views. my view directory structure looks
like this:
#flyswatter/flyswatter/views
__init__.py
default.py
task.py
admin
admin/__init__.py
admin/foo.py
The only way i managed to combine the traversal with views mapping is
like this:
#views/default.py
from flyswatter.resources import root
@view_config(context = root)
def index(request):
return Response('root::index')
@view_config(name="method", context = root)
def method(self):
return Response('root::method')
so far so good - url's "/" and "/method" are correctly mapped.
#views/task.py
from flyswatter.resources import root, Resource
root.add_child("task")
root["task"].add_child("method")
@view_config(name="task_index", context = root["task"])
def index(request):
return Response('task::index')
@view_config(name="task_method", context=root["task"])
def method(request):
return Response('task::method')
not so good - in order to access task.method i need to type the url /
task_method ( instead of /task/method ). I also cannot access
task.index by visiting /task - i need to use /task_index.
I tried to use "/task/method" as a name in @view_config but this
didn't seem to make any difference.
I think i'm pretty close to the desired result, however i am 100% sure
i am missing some crucial bit of information on understanding how
traversal / view mapping work. Could some direct me in a right way,
please? :)
best regards,
toudi.
p.s. sorry if my code looks ugly, i am still learning.. :)
p.p.s. i don't want to use view handlers - because ( unless i'm
mistaken ) i need to explicitly register the view classes one by one
in __init__.py. The config.scan() approach seems like a lot easier
( for instance for creating additional modules for the admin panel
without modyfing flyswatter/__init__.py )
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
