On 5/15/06, jvanasco <[EMAIL PROTECTED]> wrote: > using middleware, how can I do the following: > a- store a per-request variable
There's a clean mechanism for doing this that's part of Paste, but the name eludes me at the moment. > b- run code during certain segments of the request Middleware can be viewed as "around advice" in AOP terms. That means it has access to the stuff going in and the stuff coming out but doesn't really have the ability to do anything more granular than that. However, that's not to say that there wouldn't be hooks. So, if you need to be more granular than things going in and things coming out, your best bet is to stick to CP filters. > if there's going to be a change away from cherrypy, perhaps there > should be a per-request namespace/object in the next release of tg? > ie, have a tg.current_request wrap cherrypy.request, so that anyone who > is using that bit of cherrypy to manage per-request info will be > compatible There's no need, since we live in the land of dynamic languages. IF we were to not use CP, we would most definitely make cherrypy.request continue to work (in fact, RhubarbTart already does this, IIRC). Rather than forcing a transition to a potentially unnecessary intermediate name, I prefer to leave it at cherrypy.request. Believe me, backwards compatibility and a reasonable move to future technology does matter. If filters are the only reasonable way to do what you need to do, use filters and we'll figure out how migration works when the time comes. (TG itself uses filters in a couple of places, so we'd definitely have to consider it!) Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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 -~----------~----~----~----~------~----~------~--~---
