On Thursday, 23 June 2016 09:56:19 UTC-4, Anthony wrote: > > > No, the "wrapper" would be a callable object, and it can be defined >>> anywhere. wsgihandler.py is just the entry point -- you could import the >>> wrapper in wsgihandler.py and then expose it to the web server (as in the >>> built-in version of wsgihandler.py). >>> >> >> OK, this is different from what I first understood. In other words, the >> wrapper is gluon.main.wsgibase (but we can rename it in wsgihandler.py). >> > > Not quite sure what you mean. gluon.main.wsgibase is the web2py WSGI > application, which ultimately executes your web2py application (so, I > suppose in that sense, it wraps your application). However, if you want to > implement WSGI middleware, then you must create another "wrapper" (i.e., > another WSGI callable), and use that to wrap gluon.main.wsgibase. There is > already an example of this in wsgihandler.py -- when logging is enabled, it > uses gluon.main.appfactory to create a wrapper for gluon.main.wsgibase. >
Perhaps you did not read the way I explained it first, a few posts before. If you have read it, you have seen that I renamed gluon.main.wsgibase as gluon.main.wsgibase_wrapped, not in in wsgihandler.py, but the actual file. It's just a renaming, not a bad one, because it is wrapped. Also, I did not want to edit wsgihandler.py , not that it is so bad to edit it, but preferred not to edit it. Anyway, it is just terminology. It is really the same thing. > >> In fact, I was thinking that we would allow different wrappers for >> different requests, associated with different applications. So, >> gluon.main.wsgibase (what is exposed in wsgihandler.py) would not be the >> wrapper, but would only map the requests to different wrappers. >> > > Again, we can't use gluon.main.wsgibase because it is pre-existing code > (we don't want to edit it) -- we have to wrap it with our own wrapper. > Same misunderstanding, same explanation as above, but maybe you are right that there are some consequences in the renaming of gluon.main.wsgibase in the file system. It shouldn't be a problem, because the new gluon.main.wsgibase, the "wrapper", would play the same role. I put wrapper in quote - see below. > Of course, our wrapper can be a complex program with multiple modules, > etc., so we can do different things for different applications (i.e., run > different pre/post-processing steps depending on the route requested). > Yes, this is exactly what I do. This was my idea, explained a few posts before. When we do that, I would not call (using my terminology) gluon.main.wsgibase the application wrapper anymore, because its role is then to map the requests to different application wrappers. It is a wrapper, but it's not the application wrapper, which sets the configuration info and pass it. -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
