On Mon, 2010-12-06 at 10:43 -0800, Seth wrote: > Okay, so I think I'm just having a hard time grokking the idea of a > "context" (even after beating myself to death with the documentation). > > > With that in mind, let me rephrase my initial question with a more > high-level question: > > How is a large web application in Pyramid supposed to look? > > > Yes, that's a bit vague so let me clarify my thought process here: > > - If I had a webapp with, say, 70+ available "routes" it seems > silly to me to specify every single view call in the config, so I > think I'd be a real fan of the config.scan() callable and the > corresponding @view_config decorator.
Yep, makes sense. > > - TG's object dispatch (and other web frameworks I'm used to) make > the class/module hierarchy vs. url/path hierarchy pretty > straightforward, so it's more natural for me to think of a url as > traversing "controller objects" rather than having "model contexts." Pyramid just doesn't use the same paradigm, so it's understandable that you're having some difficulty. > > - All the Pyramid example apps I've seen seem to have a single > view.py containing all the "view" methods. In a larger app setting, > wouldn't you want to split these up into separate view modules? > (forgive me, I have not gone googling for examples of large repoze.bfg > apps) Sure. It's "just Python", so you can structure it as you see fit. If you use .scan(), you don't need to do anything except break the views.py module into separate modules. > > - So the issue that I'm wrestling with, of course, is how to make > the various @view_configs load the right view method from the > appropriate view module & method via a config.scan() process. If you use .scan(), there's nothing you really need to do to "make this work". Just break the views.py apart into separate modules, or create a separate "views" subpackage (a directory with an __init__.py and other .py files in it), or several subpackages, as necessary. .scan() doesn't care, it will find all the views you've defined in your entire package no matter where they live. > So maybe I want traversal, maybe I don't. Maybe I just need a "light- > bulb moment" about contexts. I think Pyramid's "different" way of > doing things just has me confused, coming from a background of using > frameworks that have a more "object dispatch" approach to urls/paths. > > > > Which brings me to my new set of questions, which are: > > 1. What would a larger Pyramid app look like directory/module wise? > Wouldn't this look more like a default Pylons 1/TG 2 setup? > (controllers-*ahem*-views in a "views" dir, models in a "models" dir, > etc) If you have lots of views, my suggestion would be to turn the "views.py" *module* into a "views" package ala: http://docs.pylonshq.com/pyramid/dev/narr/project.html#modifying-package-structure . Likewise for models. We're interested in sharing basic layout between Pyramid paster templates, and we're going to encourage people to not stray very far from the layouts they suggest. But FWIW, as far as the framework is concerned, the layout can be entirely arbitrary. It doesn't care how you structure your code. There are no "magic" directories or files. > 2. Are the Pyramid developers intentionally moving toward a less > "object dispatch" setup, and a more declarative setup where routes and > views are explicitly defined (no magic or ponies)? The Pyramid developers never had an object dispatch to "move from". Object dispatch in the terms you've definined via example so far, is a TurboGears and/or CherryPy concept. Other frameworks may do it similarly (very-early Zope2 used a similar concept) but these days it's mostly a TurboGears thing. Pyramid traversal is similar to object dispatch, inasmuch as code is found as the result of traversing some graph. But the way the code is found, and the way the graph is traversed is different. I think you're trying to draw a distinction between the two styles of mapping URLs to code by describing the Pyramid one as "explicit". To the extent that Pyramid traversal never implicitly uses a method of the objects being traversed to find a "view", I guess you could think of it this way. However, in reality, both are equally explicit, I think. TurboGears style object dispatch makes you define a method of the graph object as a "view"; Pyramid view lookup makes you register a callable using the graph object *type* as a view. If it helps at all, you might think of Pyramid style view lookup as extending how Python finds "a method of the traversed object". Instead of just doing getattr(object, method_name) to find a method which acts as the thing that returns a response, it does something more complicated. It looks up a view callable from its registry based on the object type. In a sense this view callable is a lot *like* a method.. it's a callable which accepts the context object as its first argument ("context"). If you mentally replace "context" with "self" here, you can see that it starts to smell a bit like a method, albeit a method defined external to the class definition itself. > 3. With the movement away from controllers to a view-based setup, does > this make a Pylons 1 style "map.connect('/{controller}/{action}/ > {id}')" route setup totally foreign? Not totally foreign. Inasmuch as there's no dedicated "controllers" directory in a Pyramid app, one level of implicitness is removed. But for people who like Pylons-style dispatch, there are "handlers", which are effectively Pylons "controllers", except the framework won't help to locate a controller. It will however, help to locate an *action* on a handler, so you can do: config.add_handler('myhandler', '/blog/{action}', handler='myproject.views.BlogHandler') This pattern, however, is not useful with traversal, FWIW. It's a whole separate topic. > 4. Would a typical "large" Pyramid app then have lines and lines of > route/view definitions in the __init__.py (or other config file)? Could. Or might just have a single "scan" after setting up some number of routes. Or might have no routes at all and use traversal entirely, in which case, there'd only be a single call to "scan" in there. > > > Please forgive me if all of this seems elementary to you bfg/Pyramid > experts. I've been a web developer for years but for some reason > Pyramid is making me feel like a n00b. Again, I think I need a > revelation about contexts. Not sure how to provide the revelation. I wish I could speak the magic words, apologies. - C > > > Thanks for your time, > Seth > > > On Dec 4, 4:23 pm, Chris McDonough <chr...@plope.com> wrote: > > Pyramid traversal and TurboGears object dispatch work very differently. > > In Pyramid, the graph of objects traversed isnt consulted for view > > logic. Instead, the graph is a graph of "model" objects. "Traversal" > > is the act of finding a "context". When a context is found, traversal > > has done its job. Subsequently a view is looked up based on that > > context and data in the request. > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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.
