On 1/29/11 6:14 PM, oO wrote:
Sorry if this is a newbie question, but I'm finding that I'm a little bit lost when it comes to the best way to implement an example application using MongoDB (or any non-ZODB datastore) and traversal.Conceptually, I like the idea of traversal instead of URL Dispatch but I find I'm a little bit lost as to what is the best implementation in practice, specially when not relying on ZOBD to handle the object relationship As part of the application, I'm implementing a blog section, which uses only 2 basic document (in MongoDB terms), a "Blog" and a "BlogEntry". however, from an application perspective, the URLs I need to deal with are in the form <Blog>/archive/{year}/{month}/{day}/<BlogEntry> for example: /blog/archive/2011/01/29/my-post-about-pyramid Of course, I'd eventually want to have my<Blog> resource live anywhere I want in the application, so using traversal makes a lot of sense.
this confuses me a bit. traversal is, in general, a bit _less_ flexible than URL dispatch as far as having resources live "anywhere" in an application. it's much easier to map two different URL patterns to the same view than it is to construct two different traversal paths to the same resource.
But I almost feel that the parts between<Blog> and<BlogPost> in my tree are better expressed as a URL Dispatch style patterns than by creating resources,
i tend to agree.
specially if resolving the resources means a roundtrip to the database at every single step: /blog DB do we have an object named "blog"? yes, it's a BlogResource /blog/archive BlogResource objects have an implicit child called "archive" /blog/archive/2011 DB Does this particular BlogResource "blog" have posts for the year 2011? /blog/archive/2011/01 DB Does this particular BlogResource "blog" have posts for the month 2011/01? /blog/archive/2011/01/29 DB Does this particular BlogResource "blog" have posts for the month 2011/01/29? /blog/archive/2011/01/29/my-post-about-pyramid DB Does this particular BlogResource "blog" have a BlogPostResource 2011/01/29/my-post-about-pyramid?
yup, this pretty much describes what would be happening.
Of course I could also stop anywhere in between , where I would want to see a list of BlogPosts matching that particular date range. But It seems crazy that I should have 5 different calls to the DB to resolve that path, when I would probably want, once I know I have traversed to a Blog object, to try to resolve the rest of the path with a single call to the DB. but I would love to not have to worry about the view infrastructure, because one of the things I liked about Zope is being able to declare views after the fact, completely separate from the resource objects, so I would imagine I could have "/blog/json" or "/blog/archive/atom" or "/blog/archive/2011/01/29/my-post-about-pyramid/edit" all being valid URL as well, which should match to explicit views and not just resources.
again, i'm a bit confused. zope is all about traversal, so the examples you give above are quite different from each other. the first would likely be a "json" view on the "blog" resource, the second an "atom" view on the "archive: resource, the final would be an "edit" view on the blog post resource. views are _always_ in the context of a resource with zope.
QUESTIONS: - Am I thinking too hard, and should I just use URL Traversal instead?
i suspect yes.
- Should I just do what ZODB does and implement the full resource hierarchy explicitely in my DB?
you don't have to, but it'd make things conceptually a bit simpler (than using traversal and not doing so, that is; url dispatch would be simpler yet). but it does make the content more "placeful", so you'll still have to jump through some hoops if you want the same blog post to be reachable from two different urls.
- Is there a way to create hybrid URLDispatch + Traversal application when the traversal happens first, and a resource can trigger a route match on the remaining portion of the URL?
yep: http://docs.pylonsproject.org/projects/pyramid/dev/narr/hybrid.html -r -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
