On Tue, Feb 14, 2012 at 9:46 AM, Jonathan Vanasco <[email protected]> wrote: > congrats!
Thanks. > anyways, it would make sense if the exampleapp stuff was marked up so > we know why the different items are included Addressing in private email. > 1. it looks like you dropped pyramid_handlers -- any reason? I was going to mention that in the manual but I must've put it in the Cookbook material instead. It's based on reports from some Akhet users that they started with pyramid_handlers but eventually moved to @view_config, as I myself have done. Their original reason is that @view_config can do everything @action can do but the reverse is not true. As people beyond a pure handler application to having some view functions or traversal, they have to use @view_config or config.add_view for them. Therefore, it's simpler to just use @view_config througout. I've found that I alternate between view functions and view methods depending on the situation, for instance. pyramid_handlers was originally intended to mimic Pylons, where the URL hierarchy is completely separate from the view hierarchy. As I used pyramid_handlers more, i realized it actually does more than Pylons does, and that the way @view_config splits the variables is reasonable. Also, pyramid_handlers was written at a time when add_route had all the add_view arguments, which are now deprecated. In Pylons, 'controller' and 'action' are string names in the route definition. In Pyramid, 'controller' changes to 'handler', and its value is a class (or asset spec to a class) rather than an indirect name. 'action' moves to the view as @action, or is specified both places, depending on whether you're registering a single action or all actions in the handler. As I typed my classes or asset specs for 'handler', they seemed too verbose for the config file: ".handlers.MyHandler". I then looked at @view_config, and was offended that the route name was specified there. That's routing information, not view information! But when I tried to do it the other way using config.add_view, I came to the absurd situation of listing the renderer in the main() function rather than above the view. That was even worse. Then I started using permissions and realized those needed to stay with the view. I suppose @action can handle that, but I had already gone beyond @action. Finally I decided that putting the route name with the view (as @view_config does) is not that bad: at least it ties the view to a route name rather than a specific URL. And it's better than the alternatives, of putting other view arguments in the main() function. So that's the long answer of why the demo is using @view_config rather than 'pyramid_handlers'. With the URL generator and static route, the reasoning was different. URLGenerator has no equivalent in Pyramid and is highly useful, so it stayed. The static route I've been going back and forth on. In some ways it's better than add_static_view; in other ways it's worse; so overall it's one half dozen to the other. I've been using add_static_view in my apps to get more familiar with it. So I almost took the static route out of the demo, especially when it was still a scaffold, but then I thought users would benefit from seeing it in action since they wouldn't see it elsewhere. And it's only one or two lines of code to switch between add_static_route and add_static_view, so even those who pasted the main module into their app and modified those lines wouldn't have that much work to do. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
