> 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. The code in your web2py application folder is not a WSGI application (by itself) -- rather, web2py's gluon.main.wsgibase function executes your web2py application (so, wsgibase plus your application code together comprise a WSGI application). > My question was do we have the equivalent within web2py, that is, can we > wrap an application without having to do an HTTP request? > >> >> Yes, two options have already been mentioned: >> >> 1. If you need to wrap the entire request-response cycle, you wrap >> the WSGI application exposed by web2py via middleware. This is part of >> the >> design of the WSGI standard, followed by most Python frameworks. >> >> It is a wrapper, but not a wrapper application. It makes a big difference. > Again, it is a wrapper application, and it does enable you to intercept incoming requests as well as outgoing responses, so no difference. > >> 1. If you only need to intercept the incoming request, you can add >> some code in a web2py model file (which itself could simply import a >> module >> in the Python path, such as /web2py/site-packages). >> >> This seems like a modification of the application, not a wrapper > application. > You say tomato... I made clear this is a means of intercepting incoming requests to a particular application, which is equivalent to a wrapper that only needs to modifying incoming requests (rather than outgoing responses). It is a wrapper if "wrapper" means "receives requests before the rest of the application code runs." Perhaps you require that a "wrapper" be a file that is outside the directory structure of the rest of the app code, but that would only be necessary in particular use cases. > I know it seems to do the same thing, but it is different and the > difference can be important. > I don't think functionally, but perhaps if you have limited control over filesystem structure. > Another option is to specify a custom response._caller function, which >> will wrap all controller actions (this function can be set up in a model >> file via an import from a module). >> >> >> > This is also interesting. It is not a wrapper application, but I do not > need to repeat it each time. I know that I might look stubborn, but I do > think that the original question and the concept of wrapper application is > useful. > Now it seems like you are being pedantic. Clearly I did not claim that was a wrapper *application *-- I was detailing a few different means of "wrapping" different elements of the system. > In fact, even for that specific use case, I don't think that any of your >>> suggestion totally replace what a wrapper can do. I would have to analyze >>> each of your suggestion, but most likely, in each case, there will be some >>> things possible with a wrapper that we don't have with the alternative >>> approach. >>> >> >> I disagree, but feel free to point out how a full wrapper would improve >> things for your use case. >> > > Well, this is a question that still remains to be answered. Until, it is > answered, we cannot say one way or the other. > No, it has been answered. The options offered are external to the application and will not be deleted on update. If you disagree, please provide evidence. > However, I have this feeling that it allows us to place every config > value, including the location of the config file, outside the folder of the > application. > It ain't just a feeling. ;-) > You will give me the example of environment variables, but I pointed out > that they have their own drawbacks. > Yes, but none of the drawbacks you pointed out were real. If you disagree, please provide evidence. 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
