On 3/5/06, Ben Bangert <[EMAIL PROTECTED]> wrote: > > Mike Orr wrote: > > > But why? Why cloud up environ needlessly? A thread-local global with a > > > library that any app can use up and down the chain accomplishes the > > > same thing, without clouding up environ. > > > Mainly to standardize the ways in which frameworks and libraries > > interact. A robust generic auth library could replace an auth > > middleware, but would we get into an "every library does things > > differently" situation? Would different auth implementations have a > > compatible API so you can switch between them? Would the auth library > > be consistent with your other libraries? Why is it so bad to have the > > Auth object in the WSGI enviroment; it has to be somewhere. > > Perhaps that was miscommunicated. When I refer to library, I merely > mean that there's a module of functions that you use within your > webapp. So a Identity framework package, would come with a group of > functions, and a WSGI middleware app. > > 1) You stick the middleware in front of the application you want to use > Identity with. > 2) You configure the Identity middleware to point to your db, etc, and > any other config it needs. > 3) Inside your webapp, you import Identity.functions, or whatever its > called, and use the functions > > This could work, because the Identity middleware sets up request-local > globals for use with functions that want to use data that the Identity > middleware setup when it was called. The Auth object does have to be > somewhere, its just exceptionally irritating, and massive 'repeat > yourself' to have to pass it all over the place within your app. > > That's why I use request-local module globals so that functions can get > to the Auth object, without forcing the developer to hang onto an > object that's needed all over the place by tons of functions. > > Hopefully that clarifies what I meant with 'library' vs purely > middleware. Either way you have the object and functions, and the > setup. The way I'm referring to means you save yourself the effort of > passing the environ all over the place.
A middleware bundled with library components (importable functions) certainly makes sense, since it gives more flexibility to the controller. I was not complaining about a WSGI-library hybrid, but of an idiosyncratic library that avoided WSGI for no good reason. The 'email' library in another message, presented as superior to a WSGI alternative, is not an example. (1) the 'email' package doesn't do anything web specific, (2) it doesn't carry state across requests or sessions. Therefore it has no reason to be middleware. But anything that's related to identity or sessions or redirects or page wrapping or cookies etc should probably be WSGI'ified unless there's a good reason not to. "Useful in only one application or framework" would be a good reason not to. "Not reinventing the wheel (even if we already have)" would be a good reason to. And I can see the point for turbogears.request.wsgi [1] or such so you don't have to pass the environment around everywhere. The point of middleware is to be framework-neutral, not to force everything through the environment. [1] I'm assuming cherrypy.request will go away someday, since it notionally ties us to a package we're not 100% happy with, and using a fake 'cherrypy' module for compatibilty screams of kludge. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
