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 <tors...@irlaender.de> wrote: > > 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 Everitt: > I think what some people do is put *one* object on the request, such as > request.api, as an instance of a class with a bunch of @reify properties and > methods such as request.api.db. > > This lets you avoid the kind of pollution and potential collisions that you > warned about. > > —Paul > >> On Jan 29, 2016, at 7:35 AM, Torsten Irländer <tor...@ <>irlaender.de >> <http://irlaender.de/>> wrote: >> >> 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 be a widley used >> pattern) to it, and some other small thing. But I am wondering how the >> request is meant to be used. Is it OK to use the request for such things? I >> tend to say that adding more and more properties to the request (even if >> they are related to the request) is some kind of misuse and not intended by >> the developers. >> >> What do you think? >> >> For those who are interested in some background of this question: This >> questions arised when talking about how to implement Feature Toggles. See >> https://github.com/ringo-framework/ringo/issues/6 >> <https://github.com/ringo-framework/ringo/issues/6> >> >> best regards, >> Torsten >> >> >> >> -- >> 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...@ <>googlegroups.com <http://googlegroups.com/>. >> To post to this group, send email to pylons...@ <>googlegroups.com >> <http://googlegroups.com/>. >> Visit this group at https://groups.google.com/group/pylons-devel >> <https://groups.google.com/group/pylons-devel>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > 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 > <mailto:pylons-devel+unsubscr...@googlegroups.com>. > To post to this group, send email to pylons-devel@googlegroups.com > <mailto:pylons-devel@googlegroups.com>. > Visit this group at https://groups.google.com/group/pylons-devel > <https://groups.google.com/group/pylons-devel>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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.
