Maik, Am Samstag, 30. Januar 2016 05:25:41 UTC+1 schrieb Mike Orr: > > 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 request. So I would do likewise, starting with > database connections. > > In one application I have SQLAlchemy sessions to three databases, the > underlying engines to them, a Redis connection pool, an ldap3 pool, > things from tweens, and maybe other things. I tried different > strategies like add_request_method, a request subclass, and > pyramid_services. I ended up using a request subclass just because it > was easier to manage all those things together rather than piecemeal, > If I had only one or two I'd use add_request_method. And I use reify > as much as feasable. >
Thanks for sharing your experience. I have currently only the need for little things to be added to the request so the add_request_method seems to be my way, but the more I think about using the request object for more things I like the idea of a subclass also :) > > The features example you cited has an object that knows about the > features. But aren't boolean features ultimiately controlled by > configuration settings to enable them? Yes, I thought of putting the configuration into the ini file. > You may be able to just use the > settings, or define your own settings, and then you wouldn't have to > make custom request properties. > This was definitly the preferred way before I know that I have other options to make the flag for the feature directly available in the request. I was about to write a helper method which returns the value of from registry.settings. This is pretty simple and straight forward and just does its job. Especially for the "Feature Toogle" thing I think I'll stick with the helper method appraoch to stay consistend with the current way to do things in my application. The biggest challange for me now is to stay calm in the face of the new and very interesting and tempting alternatives and ideas you have offered to me. And to *not* change things just for the reason there is a more elegant way ;) > On Fri, Jan 29, 2016 at 4:35 AM, Torsten Irländer <tor...@irlaender.de > <javascript:>> 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 > > > > 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 <javascript:>. > > To post to this group, send email to pylons...@googlegroups.com > <javascript:>. > > Visit this group at https://groups.google.com/group/pylons-devel. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > Mike Orr <slugg...@gmail.com <javascript:>> > -- 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.
