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 email@example.com. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.