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.

Reply via email to