On Tue, Nov 25, 2008 at 9:50 AM, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: > > On Tuesday 25 November 2008 16:31:09 Gustavo Narea wrote: >> Hello, Diez. >> >> I know that's another option, but Chris McDonough has already explained to >> me >> >> why that should be avoided. This is a part of the conversation: >> > > So, before implementing such a functionality with a thread-local, I >> > > wanted to ask: Why did you prefer passing the environ around instead of >> > > using a thread-local? >> > >> > The reason the Pylons folks need the StackedObjectProxy (which is a bug >> > and confusion magnet) is because they use thread locals like this to >> > represent request-local state. For instance, when one Pylons application >> > calls into another via WSGI, this thing stacks the environment in such a >> > way that one application doesn't stomp on another's thread-locals. >> > >> > SOP is nasty, and I suspect using a "bare" thread local will become >> > problematic in oddball environment configurations like the above, so were >> > it me, I'd write it in such a way that the "raw" repoze.what stuff >> > expects the environ to be passed in. In any case, if you do end up using >> > thread locals, I'd put the thread local stuff in the *calling* app, and >> > not in repoze.what itself. >> >> That's why I prefer repoze.what to be passed the environ every time it >> needs the environ. > > I understand that sentiment, and if repoze.wha and what are supposed to be > independent middlewares - so mote it be. > > From and end-user POV however this is a moot point. I don't have the environ > available in TG2. Django makes these things explicit - TG doesn't. > > So not putting them into repoze.what will introduce the need to wrap them > again, passing the explicit environment which is fetched from some > thread-local storage (or even the SOP, to keep mulit-apps possible I presume, > yet I don't know when such a stack is pushed/pop'd). > I agree with Diez here. if repoze.what's goal is to be framework agnostic then this type of thing should be inside repoze.what. That way if you are using pylons or TG or whatever you will have one true way across frameworks. if we start adding small things at the framework level it's going to be a problem.
For example with pylons there is no auth in the core so where is this supposed to land? where will the require and the current_* methods be in pylons? I'm thinking they will end up on a wiki and/or doc page where you will be required to copy into your project. SOP is at the core of pylons but it allows you to do a lot of interesting stuff, so I say it's a necessary evil. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
