Ben Bangert wrote: > Kevin Dangoor wrote: > > > Before I left yesterday, Gary Godfrey told me about his next step with > > that branch and his change was going to make it even more flexible and > > useful by making each controller class a "WSGI app" with the ability > > to insert "middleware" at any part of your stack. You'll also have > > incredible control over how object traversal wants *if you want to*. > > I'd be interested in hearing how this works out. Similar things were > considered for Pylons controllers, however it seems to greatly > over-complicate things when you make individual controllers true WSGI > apps, vs merely objects that you call with a WSGI interface. The latter > still allows for insertion of some types of "middleware" at any part of > the stack, though since your application itself is typically a > collection of 'controllers', rather than each individual controller > being an App capable of functioning totally independently.... it warps > a bunch of terminology that will likely drive many people insane. :)
OK - I'll outline some of my current thoughts and let you pound on 'em. I'll be glad to hear what type of things you ran into with pylons. So, the general idea is that everything is wsgi until it can't be. So a TurboGears controller is wsgi middleware which (by default) takes one item off the url and uses it to wsgi call self methods. It may also have other uses, like capturing a Form Validation Exception and calling appropriate error methods. This also imples that the @expose decorator is really a wsgi adapter. The fun part about this is that a (for instance) Authorization check just needs to be simple wsgi middleware and it works on whole controllers as well as with individual methods with a single routine. What also will begin to happen (or at least should happen) is that we'll start using the environ dict in a more expanded fashion. I'm thinking of something akin to Zope3's Interfaces, but not so formal. So, "Identity" middleware will set a "wsgi.Identity" which will contain UserName, Groups, Roles, Permissions, etc. Then, a Authorization check is completely separate from the Identity mechinism. I suspect we'll need something like PEPs just for this (it will have to move far faster than PEPs do - especially initially). Vision: a TurboGears application should run under Zope that has a wsgi interface and may even be able to handle simple permissions. > Great to hear about the continued drives for deeper WSGI integration. I > should note that while Pylons currently uses Myghty resolving in the > core, its on the road-map to split out the resolver sequence to a more > WSGI styled approach which is where RhubarbTart appears to be going. > This means that future TurboGears versions will vary very little from > future Pylons versions. Good times ahead! RT was doing some half wsgi / half CherryPy things in the URL traversal. We started going down that path and realized that it would be pretty easy to just use wsgi everywhere and get the same effect (actually better effects in several important ways). So RhubarbTart seems like it's falling out (being replaced with very little code). Some things that are gumming me up now are: 1) How to communicate upstream? For instance, if I want to logout, I need to let the Identity middleware know that. Can I set something magic in environ? Do I have to throw an exception? 2) What if I need to "fork" mutiple wsgi requests. This could easily happen on a "three column" web page where the right hand side contains the summary and the main area contains the real thing. I suspect it just means intercepting the start_response() call, but I'm not sure. 3) The wsgi standard says that no inspection of wsgi applications is allowed. This is unforunate because we currently rely on things like an "expose" property on controller methods which are callable. At the very least, I'd like to start an informal standard that a 'wsgi' property be on all wsgi callables. That should be enough to prevent uncallables in Controllers from getting called by Evil URLs. Cheers, Gary Godfrey Austin, TX --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
