Make the stuff under request.api either as methods or @reified properties. That
way, on each request, you only pay for what you eat. Anything you don’t use in
that request, doesn’t get evaluated.
—Paul
> On Jan 29, 2016, at 8:07 AM, Torsten Irländer wrote:
>
> Hi Paul,
Hi all,
The request is available almost everywhere is a pyramid application. This
makes it seductive to use the request to pack many more properties to the
request und (mis?)use it as a carrier for some kind of "dependency
injection".
I already added the current DB connection (which seems to
Hi Paul,
Thanks for the hint. This might be an option! Do you have concerns that the
request might get to big and and slows the application down when there are
to many things under the namespace "api"? And when is big too big?
Torsten
Am Freitag, 29. Januar 2016 14:00:08 UTC+1 schrieb Paul
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
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
The request is for anything you need. Some frameworks pass a request
and response to the view and have other global objects and things, but
Pyramid tends to use the request to put all that stuff in one place.
Even semi-exceptions like 'context' that can be received separately
are also in the
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