Actually a bit more in keeping with the spirit of Traversal, and again
keeping your calls to Mongo to a mininum, would be something like
this:
/blog/month/2011/01/29/my-post-about-pyramid would do this:
archive = Blog['archive']
year = archive['2011'] = archive.__getitem__('2011') = Year(y=2011)
month = year['01'] = year.__getitem__('01') = Month(y=2011, m=1)
day = month['29'] = month.__getitem__('01') = Day(y=2011, m=1, d=29)
post = day['my-post-about-pyramid'] = day.__getitem__('my-post-about-
pyramid') = Post(y=2011, m=1, d=29, slug='my-post-about-pyramid')
... and the default view for Post would be to query Mongo
This would handle shorter paths in a natural way -- e.g. '/blog/month/
2011/01' would map to the default view for Month(y=2011, m=1), which
would call Post.list_posts_for_month() .
On Jan 30, 9:04 am, Wade Leftwich <wleftw...@gmail.com> wrote:
> 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.
