On Tuesday, 21 June 2016 00:20:07 UTC-4, Anthony wrote: > > 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. >> > > wsgihandler.py is *where* you would call the entry point to your wrapper > application (and by the way, it doesn't have to be there -- you could put > it anywhere, as long as you tell your web server where it is), but the > wrapper application code itself can be wherever you want, and it can be as > complex as you want. It would indeed be separated from the wrapped > application. > > >> we know that the wrapper as to be created as we created the wrapped >> object. >> > > Why? What are you doing that necessitates this requirement? In PHP, your > wrapper application probably doesn't look like the wrapped application, > other than that it is inside a .php file (which is also the case with WSGI > middleware, which is just Python code in .py files). > > It is related to the fact that the solution is a modification of how we connect with an HTTP server. If I move back the code on the rocket server, I lose the wrapper, because this modification is not implemented for this connection. With PHP, I do not need to change the way the connection to the server works. I could change the web server and it would still work in the same way. So, modifying wsgihandler.py is not totally what I want. Perhaps an alternative and more robust solution would be to wrap gluon.main.wsgibase with some code outside web2py, because I suspect that all handlers use the same base.
Also, I got confused by the fact web2py handles the HTTP requests via a single function gluon.main.wsgibase, which deals with the pathinfo. In the case of PHP, I can have different wrappers (in different files) for different requests, because distinct requests are mapped to distinct files. If we want, the wrapped application can be requested directly, without modifying any code. The fact that we do not have this here created the feeling that this wrapper is not really a separate application from the wrapped object, which in this case is web2py. Moreover, the fact that the code of the wrapper was originally within the web2py folder, really created the impression that it was not at all a separated application. At the time, I did not have successfully parsed your sentence that says that we can move the code outside, because it was a parenthesis. I still had doubts about what you meant. > Anyway, this is one reason it helps to articulate specific use cases. You > make claims about how a "wrapper application" *must* look without > demonstrating *why* it must look like that. What are the use cases that > demand this particular approach? I'm not saying web2py can easily handle > all possible cases, and its execution model probably does introduce some > limitations, but it would be easier to explore the limitations and possible > workarounds with some concrete examples (the one use case you have provided > is trivially easy in web2py). > > Anthony > -- 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.
