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. Only it will be more difficult to avoid these pitfalls if there is more code.
> 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 never tried that with a PHP framework, but I don't see any fundamental >> issue. If you know PHP and see a fundamental problem with this, let me know >> concretely what it is. >> > > 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. > 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. > > 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. I know it seems to do the same thing, but it is different and the difference can be important. Note however that I do take note of every thing. I am not stupid. Even though it is not an answer to the original question, I agree that it can be useful > 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. Also, if you just need to wrap a view or set of views, you can extend a > view file (with a view that exists outside the current application if > desired). > > >> I was not expecting to have to motivate the usefulness of this, but just >> wanted to know if it is possible. I am not saying that I do not find >> useful your suggestions how to pass configuration values in web2py, but you >> forget that I mentioned in the question "never mind this specific use case, >> because the objective here is very standard and general." >> > > Yes, acknowledged, which is why my first response provided exactly the > answer you sought. I only offered the other suggestions to help provide a > more appropriate solution for your use case. > Well, as I said in another post, we accumulate tools, offer tools, and it is up to the person who design a particular approach in practice to use them, if they are useful. > > >> 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. 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. You will give me the example of environment variables, but I pointed out that they have their own drawbacks. Sure, using a file within the folder of the application might not be a big deal. This was one of your very first point, you said something like "just need to make sure that it is not erased or rewritten." Yep, but it is still annoying in my opinion. So, if we can avoid that, it is an improvement. > > >> I am sorry that you put me on the defensive, but perhaps you are also on >> the defensive regarding the capabilities of web2py. If I did not think >> that web2py is great, I would not be here. It was just a question regarding >> wrappers. Now, if the feeling is that I am trying to prove that web2py is >> limited and you try to prove that I am wrong, then you will never address >> the question for what it is. >> > > Again, I'm not sure where this is coming from, as I thought I quite > directly addressed your original question. If you *need* a wrapper, use a > wrapper, but most of the discussion was about this particular use case and > other simpler alternatives. > > Sorry, maybe it's me. However, it is OK. I just want to progress. > However, I am in the defensive when you go as far as saying that I should >> drop the concept of wrappers as it if it cannot be useful. >> > > I don't not believe I said the general concept cannot be useful -- I only > said it wasn't the best option *for this use case*. > > Great. > I was expecting a more open perspective. >> > > I thought offering additional, more appropriate options did reflect a > fairly open perspective. > > Great -- 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.
