One thing is for sure though, I would not define the resources in the same area as the view call-ables, for proper separation of concerns.
On Thu, Mar 3, 2011 at 12:18 AM, Joe Dallago <[email protected]> wrote: > That is really the beauty of Pyramid, they can literally be defined > ANYWHERE. By convention, one would probably look in a models.py file > in the root of your project or in a models directory for all of your > resource definitions. The only thing that really needs to know where > your resource tree is, is the Configurator. When you pass a > "callable," which can either be a class that has an _init() function > defined or a function, to the Configurator's "root_factory" keyarg, > you are defining the point that the router starts its resource tree > traversal. > > On Wed, Mar 2, 2011 at 11:17 PM, pspringmeyer <[email protected]> wrote: >> A good overview. Thank you. >> >> The other question I have, is, where are resources defined and >> configured? All the examples show example resource code but I have no >> idea where a resource is supposed to be defined - in the same module >> as the view callable? >> >> On Mar 2, 7:34 pm, Joe Dallago <[email protected]> wrote: >>> So I am relatively new to the Pyramid scene, so correct me if I am >>> wrong, but this is the conclusion I have come to on this topic. B/c I >>> too struggled for a few days over this. >>> >>> Resources: First of all, resources were originally called "models," >>> but the name was purposely changed to avoid confusion with SQLAlchemy >>> "models" or with the normal idea of what a MVC "model" is. A >>> "resource" is simply one element in the "resource tree." The entire >>> purpose of the resource tree is to define the structure of your site. >>> A resource isn't necessarily connected to a persistence system, such >>> as an RDBMS, but it definitely can be. It is also important to note >>> that the resource tree is only used when traversal is used as the >>> routing system. Traversal is simply the process by which the router >>> moves down the resource tree according to the url, and assigns the >>> context and view. >>> >>> Context: In traversal, the context is the last resource that is >>> loaded as the router traverses the resource tree, either due to the >>> fact that there are no elements left in the url or that the router has >>> reached the bottom of the tree. >>> >>> View: The view is element of the url that directly follows the >>> context(i.e. /pages/add, if 'pages' is loaded as the context, then >>> 'add' becomes the view). It is essentially the function that does all >>> of the business logic and sends important information to the template. >>> In traversal the context found through the traversal is passed into >>> this view function, whereas in Url Dispatch, the root_factory defined >>> when the view is added to the registry creates an object that is >>> passed into the view as the context(this could be the root of your >>> application or even another resource that you might want to use in the >>> view, it just has to be a class). >>> >>> I don't know about the zope.interfaces question. >>> >>> I always use the 'view_config' decorators. It is the most readable >>> option, and I would think readability would only become more important >>> on a large web application. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Mar 2, 2011 at 8:20 PM, Chris McDonough <[email protected]> wrote: >>> > On Wed, 2011-03-02 at 17:07 -0800, pspringmeyer wrote: >>> >> I've been able to figure out most everything about Pyramid, but there >>> >> is one thing that I'm not able to "grok" and that is "resources". I'm >>> >> not really understanding the connection between resources, contexts, >>> >> and views. I'm also confused as to why I would want to use >>> >> zope.interfaces with a resource... >>> >>> > Likely just dont think about it. Use url dispatch instead. Then you >>> > don't need to know anything about contexts, resources, interfaces, none >>> > of it. >>> >>> >> Another question: is it more idiomatic for a large web application to >>> >> imperatively declare views or to use the scan() method + config >>> >> decorators? >>> >>> > .scan() is more convenient so it's used more frequently. >>> >>> > - C >>> >>> > -- >>> > 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 >>> > athttp://groups.google.com/group/pylons-discuss?hl=en. >> >> -- >> 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. >> >> > -- 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.
