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.
- 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."
- 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)
- 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.
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)
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)?
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?
4. Would a typical "large" Pyramid app then have lines and lines of
route/view definitions in the __init__.py (or other config file)?
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.
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.
