Suggestion for Request namespace provisioning
The past few updates to Pyramid have had a few changes around the Request object - new attributes, new functionality to add attributes, etc. With that, combined with the best-practice of passing the Request object around during the request lifecycle, I wanted to suggest creating a 'project' and 'plugin' namespace under request , so that (moving forward) as people develop plugins or write app specific request attributes there is no issue for collision against each other or future Pyramid releases. The general idea would be this: request.project = reserved for your app ( or request.projects.project_name ). do what you want. request.plugins = reserved for plugins that need to attach data to the request object. ex: request.plugins.sqlalchemy The main idea is that instead of using 'set_property', you'd use 'set_project_property' or similar. Not suggesting that we drop the current scenario, just that - the request object has a lot of stuff in it now - i can see the request object's attributes/methods growing as Pyramid matures - i fear namespace collision. -- 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.
Re: Suggestion for Request namespace provisioning
That pattern / functionality is great. I'm just talking about proactively saying this name space is reserved for plugins, this namespace for projects - you can rest assured that as Pyramid grows and new functionality is added, you will not be affected as long as you stay within that container. Right now, request.foo is a bit of a lottery -- from my perspective, chances are you won't add anything to Pyramid over there, but its not an explicit/futureproof property. -- 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.
Re: Suggestion for Request namespace provisioning
On Tue, Oct 30, 2012 at 3:34 PM, Jonathan Vanasco jonat...@findmeon.com wrote: That pattern / functionality is great. I'm just talking about proactively saying this name space is reserved for plugins, this namespace for projects - you can rest assured that as Pyramid grows and new functionality is added, you will not be affected as long as you stay within that container. Right now, request.foo is a bit of a lottery -- from my perspective, chances are you won't add anything to Pyramid over there, but its not an explicit/futureproof property. I think it's cool that Pyramid provides a way to do it, but I don't think layering that opinion on top belongs in the core. -- 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.
Re: Suggestion for Request namespace provisioning
On 10/30/2012 04:49 PM, Michael Merickel wrote: On Tue, Oct 30, 2012 at 3:34 PM, Jonathan Vanasco jonat...@findmeon.com wrote: That pattern / functionality is great. I'm just talking about proactively saying this name space is reserved for plugins, this namespace for projects - you can rest assured that as Pyramid grows and new functionality is added, you will not be affected as long as you stay within that container. Right now, request.foo is a bit of a lottery -- from my perspective, chances are you won't add anything to Pyramid over there, but its not an explicit/futureproof property. I think it's cool that Pyramid provides a way to do it, but I don't think layering that opinion on top belongs in the core. Also, FWIW, even if people add some namespacey thing, those namespacey things themselves are subject to conflict. So telling folks to bundle up everything into a namespace isn't a complete solution either. The only true solutions are untenable without ridicule (UUIDs, Java-style com.pyramid.myplugin style namespaces). I'd rather just let the chips fall where they may here and instruct folks to create plugins that don't supply unduly generic request properties. If they supply one, so be it; the system will let the user know there's a conflict, and they can work it out with the authors. Note that this is how Emacs plugins have worked for many years, and Emacs has a *lot* more plugins than does Pyramid. ;-) And they don't even have conflict detection. - C -- 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.
