[pylons-devel] Re: Adding custom properties to the request, or how is the request meant to be used?
Read the docs on `add_request_method`. It's pretty great. I think the docs continue on the set property method, and explain the pattern a bit more. Anyways, combined with reify, there is very little overhead. You can also use dotted-name strings to register, which can make things a bit easier for writing extensions/plugins. Just to clarify my earlier point: If you were merely building your own application, I would do everything on the request itself. Since you're building/maintaing a framework though, I think you may be better off with your own "context" objects that gets tossed onto the request. That could give you better control of modules/plugins registering with your application. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
[pylons-devel] Re: Adding custom properties to the request, or how is the request meant to be used?
Jonathan, Thanks for your reply. It helps me to mitigate my concerns on how to use the request. Especially yours and Pauls pointer to @reify is of great value. I must admit that I wasn't aware of this. What a pitty after working so long with pyramid :/ Thanks to your answers, I am now equipped with new options to solve problems! Am Freitag, 29. Januar 2016 20:09:07 UTC+1 schrieb Jonathan Vanasco: > > I have about a dozen reified request properties on an application. > They're great. > > It's entirely possible to abuse it – but that's what coding standards are > for. > > We have about a dozen objects on our request. They could be consolidated > into a smaller, nested, hierarchy... but they're all "request specific". > > A few of our properties are documented as "public" – and ensured to work > across our application. A few of them are documented as "private" -- > they're enabled(registered) by a single component that may or may not be > enabled. No code outside that component can touch it. (for example, our > caching layer and some environment-specific debugging). > > Pyramid's implementation of add_request_method + reify meant there's > virtually no overhead during runtime (95% of them are never called during a > request). We could have created a singular "api" namespace, but then we > would need to re-implement the add_request_method for registration and > management. That seemed onerous. > > Looking at the example you gave, since you're doing this on a framework, I > think it would be a bit different. > > Personally, I would create a reify'd '.ringo' property on each request for > the "public api" (and possibly use `_ringo` for non-public/core usage). I > would have that property be a request-specific context object. > `request.features.FOO` could be a way to handle the > `request.registry.settings` data. functions could then either rely on > `request.ringo` or be invoked with the context object as an argument. > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
[pylons-devel] Re: Adding custom properties to the request, or how is the request meant to be used?
I have about a dozen reified request properties on an application. They're great. It's entirely possible to abuse it – but that's what coding standards are for. We have about a dozen objects on our request. They could be consolidated into a smaller, nested, hierarchy... but they're all "request specific". A few of our properties are documented as "public" – and ensured to work across our application. A few of them are documented as "private" -- they're enabled(registered) by a single component that may or may not be enabled. No code outside that component can touch it. (for example, our caching layer and some environment-specific debugging). Pyramid's implementation of add_request_method + reify meant there's virtually no overhead during runtime (95% of them are never called during a request). We could have created a singular "api" namespace, but then we would need to re-implement the add_request_method for registration and management. That seemed onerous. Looking at the example you gave, since you're doing this on a framework, I think it would be a bit different. Personally, I would create a reify'd '.ringo' property on each request for the "public api" (and possibly use `_ringo` for non-public/core usage). I would have that property be a request-specific context object. `request.features.FOO` could be a way to handle the `request.registry.settings` data. functions could then either rely on `request.ringo` or be invoked with the context object as an argument. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
