On Monday, 20 June 2016 23:21:45 UTC-4, Anthony wrote: > > > On Monday, 20 June 2016 18:59:58 UTC-4, Anthony wrote: >>> >>> >>>> >>>> I think the concept is easy to generalize to an application, to a >>>> script, etc. >>>> >>> >>> The *concept* is easy to generalize, but the *implementation* may >>> become more complex as you move from a simple single-page PHP script to a >>> full-blown web framework. >>> >>> >> Maybe it is not that complicated. It certainly is not in PHP. It may be, >> but I don't see how, but it may that there are some pitfalls, which are >> more likely to be present with a complete application, but I don't see >> this. I am just open to the idea that these pitfalls might exist. In any >> case, the way to do that will not change, it would still be a simple >> include. >> > > You claim it is simple in PHP, but you admit you have no idea how to do it > in the context of a web application developed with a PHP web framework. > Then how do you know it is so simple? Please just show some example code > based on one of the many popular PHP web frameworks comparable in scope to > web2py. > > Anyway, I would say the WSGI middleware approach is also fairly simple. > You just create a wrapper function, let it do what it needs to do, and then > call web2py's WSGI application function (i.e., gluon.main.wsgibase). The > call to the web2py function will be a single line, much like your single > line include in PHP. > > >> In the case of PHP, we can do that with a simple include of the script >>>> that would have been called by the original HTTP request. >>>> >>> >>> That sounds like a single-page PHP script. In web2py, if you just want >>> to serve a single page, it is equally easy to do an include like this. >>> >>> >> >> It is interesting that in web2py, there is a distinction. In PHP, a full >> blown application is still a script. You will include it in the same way. >> > > I don't know, this <https://github.com/bestmomo/laravel5-example>seems a > bit more complicated. > > > >> I do not know PHP frameworks well, but you claim it is easy, so I will >>> leave it to you to show an example. Anyway, you seemed dissatisfied with >>> the WSGI middleware approach, so I was prompting you for an example of how >>> you would handle this in other frameworks to see if web2py can provide a >>> close analog. >>> >>> >> >> This is indeed a wrapper, but it is not a wrapper application that >> directly receives the HTTP request. This is why it does not have the same >> quality that we would expect from a wrapper application which receives the >> HTTP request. To be a wrapper application, it had to be first an >> application. >> > > I don't think you understand WSGI. A WSGI compliant framework exposes a > WSGI *application*, which must be a callable object (e.g., function or > instance of a callable class). web2py's WSGI application is > gluon.main.wsgibase, and it absolutely does receive and respond to HTTP > requests. The web server calls the application and passes in all of the > request data, and the application returns a response to the web server. You > can nest WSGI applications, so each outer application is indeed a wrapper > around those inside it. > > Yes you are right. I actually read in the book that gluon.main.wsgibase does receive the HTTP requests and, now that I remember, this is most likely why I decided to view this as a wrapper application. This discussion is useful, if we can limit it to the process where we learn. Clearly, on the other hand, from another point of view, the one that matters for our purpose, it is not a wrapper application. I believe that it is an issue of "layers" and I need to explain what I mean here, because it is not the concept of layers as in TCP Vs HTTP, etc. Somehow, the application is a layer above the script wsgihandler.py and above gluon.main.wsgibase, but this concept only exists in the structure of the code. In the code, we see a folder in the applications folder and somehow this is what corresponds to the application at the code level. Now, you are right that, when seen from another layer, i.e., the actual process, it is gluon.main.wsgibase that receives the request, because the concept of application does not even exists in that layer. However, for a programmer, the application is what is created when we create a new folder in the applications folder. A wrapper application has to be an application separated, in terms of its declaration, from the wrapped application. I know you told me that I did not define rigorously what is a wrapper application and I totally agree, but we do have a natural notion of what it is and, as in the case of a wrapper function, we know that the wrapper as to be created as we created the wrapped object. A wrapper for a function is an ordinary function that calls the wrapped function. Even without any rigorous definition, I see that there is no creation of a wrapper application when we modify wsgihandler.py within the wrapped application. It's not at all what we call a wrapper application. The fact that it has to do with the code, what is seen by the programmer, makes it very relevant. I appreciate very much your comments. They well thoughts. I hope that we will not be fighting each other. I do think that there is something real here, which does matter even at a practical level.
-- 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.
