If you want to stick with Traversal, don't forget that you have
request.subpath available to you. For the path "/blog/archive/
2011/01/29/my-post-about-pyramid", you could have an Archive context
whose default (unnamed) view would be called with a request that
included request.subpath = ['2011', '01', '29', 'my-post-about-
pyramid'].
The view would then call a method on the Archive context using
arguments constructed from the request.subpath. The Archive would in
turn make a single call to Mongo. A path like '/blog/archive/2011/01'
would require some logic in the view, to choose a different Archive
method and a different template to show a listing of posts for
January, or perhaps redirect to /blog/month/2011/01 .
So if you are using Traversal in this way, the logic for parsing the
path lives in the view and/or the context. With URL Dispatch it's in
the configuration.
-- Wade
On Jan 29, 9:14 pm, oO <oliv...@ozoux.com> 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. 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, 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?
>
> 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.
>
> QUESTIONS:
>
> - Am I thinking too hard, and should I just use URL Traversal instead?
> - Should I just do what ZODB does and implement the full resource
> hierarchy explicitely in my DB?
> - 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?
>
> oO
--
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.
