Fun stuff. BTW, if it didn't come across in my last message, I really
got a feeling of "drinking the cool-aid" during pycon. Finally "got"
paste (and many aspects of TG) that I didn't before. Some of the
zelotry will likely wear off soon :-).
Ben Bangert wrote:
> There's several things that lose features if moved purely to
> middleware, like Auth functions, where you might want to do,
> Auth.user_can(permission='edit_people'), even though the environ might
> not contain anything having to do with users or permissions. So while
> WSGI sounds great, and it is, for a lot of things, it definitely has
> its place, and library functions work great for a lot of this as well.
The main issue that I have with library functions is that it's not
(currently) portable across frameworks. I can't do:
from <current running parent framework> import Identity
So I'm thinking of using environ as a proxy. You can still do calls
within this scope (just for example):
environ['Identity'].user_can(permission='edit_people')
Now, I hope that someday the different frameworks might be able to get
together and have a generic import mechinism, but I think that's a ways
off. Right now, wsgi is the only thing that we have that might have a
slight possibility of maybe bringing the frameworks together. So I'm
hanging a little more here than I would if it were a purely techinical
decision.
> 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.
I sort of like the idea that environ as the primary thread-safe area to
use. We need to be _very_ careful about namespace and clutter, but the
same is true for any namespace.
> environ can be loaded up with objects and functions. So rather than
> sending a message upstream, we can just keep some of the upstream
> functions around downstream as needed.
Cool - I can see a big thing here is documentation. It's going to be
very easy to get this thing confused! I'm also envisioning that the
docstrings for these routines should have dot embedded in them. Now,
how to automagically create a pretty graph which automatically searches
the source and looks for callbacks and exceptions up the wsgi stack...
> > 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.
>
> It's a bit more complicated I think. This is also what Ian Bicking
> proposed using HTML overlays for, as it'd make it a bit more feasible
> to assemble different sections of a page with different wsgi apps.
Cool - I hadn't read that before. It sounds like a great way (from an
Application designer standpoint) to implement this. I suspect it could
be implemented fairly easily using paste.recursive, but it could be
that I just don't understand it well enough yet <g>.
> Alternatively, you could enforce a policy, ie Python's, and declare
> that private methods use _ in front. In Pylons, after looking at more
> than a few different Controller styles, I went with the callable style
> utilized by Aquarium. It's incredibly 'Pythonic', and super-flexible.
> That is, the controller is required to be a callable, and is called
> with the method name as the first arg, the rest of the methods normal
> args as the remainder.
That's sort of what we have with WSGI, isn't it? The only difference
is that the method name and additional parameters are pulled from
environ['PATH_INFO'] rather than passed in parameters. I am thinking
of making a function or two which will make managing this while doing
RESTful stuff a bit easier.
> Consider the current TG solution, where you might have to drop the same
> decorator on a dozen different methods requiring the user to be logged
> in for all of them. Talk about repeating yourself. If you had a
> __call__ style, you could say that being logged in is necessary for all
> the methods except 'login', in a mere 2 lines of code by checking the
> method name against a list of what requires it.
Again, still easy to do WSGIish (top of head, no error checking)i:
def __call__(self, environ, start_response):
tgEnviron(environ) # Make sure environment has things in place
# lc path_info has PATH_INFO split on '/' and cleaned up.
if not environ['path_info'][0] in ['Login','Logout']:
identity.require(environ, identity.in_group('admin'))
return self.defaultCall(environ, start_response) # standard
Controller __call__
> Finally, if each controller is a wsgi app, does that mean it has to
> setup the thread-local globals again for the current application?
Nope - only the wsgi Server/Gateway side needs to worry about that.
environ is thread safe - if we hang everything there, then we're safe.
> I think my main issue with making each controller a wsgi app, is that it
> really isn't.
You're right - each controller is really WSGI middleware.
> If you consider a WSGI app to be a stand-alone
> application (which I think it should be), then it doesn't make sense.
I'm not sure I entirely agree there - I can see room for WSGI apps that
are irrelevent stand alone (a menu system, for instance).
> Controllers depend on other controllers being where they are, because
> controllers are all part of a single application. WSGI apps don't care
> about anything outside of them-self.
I think this is a terminology issue. I'm thinking that an
"Application" is a WSGI middleware stack with WSGI applications hanging
off on the leaves. The architecture of the middleware is part of the
Application.
> Does each controller have to parse environ, and setup a request object
> again? There's a lot of setup stuff a framework does when it starts
> handling a WSGI call, is that all going to be pushed into each
> controller?
Again, I think it's completely valid (and necessary) for Applications
to make assumpions about upstream middleware. I'm assuming that a TG
application which is running under a different Server/Gateway would
have a small piece of middleware which marshalls the enviorn
appropriately to resemble the normal TG Server environment.
Ciao,
Gary
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
