On Monday, June 20, 2016 at 3:24:46 PM UTC-4, Dominic Mayers wrote: > > Anthony, I am going to reply to one specific part of your last post, the > one with "I don't think the concept of wrapper application is well > defined.": > > I don't think the concept of "wrapper application" is well defined. In any > case, we should probably drop that idea, as your ultimate goal is not to > have a "wrapper application" but instead to have some configuration data > made available to your application -- so let's focus on that. > > I should not be here to defend the usefulness of a wrapper application or > even rigorously define it. >
You were not asked to defend the usefulness of a wrapper application. I also don't know why you are hung up on this, as literally the very first thing I mentioned in my first response was how to create a wrapper application. The rest of the conversation has largely been about simpler alternatives that would be more appropriate for your particular use case. You seemed interested in those alternatives, as you continued with follow-up questions and concerns, so I continued to provide further detail and options. > I believe that the notion of a wrapper is sufficiently general that I > should not need to define it. > I was just saying it isn't well defined in the context of web2py, as there are different elements of the system you might want to wrap (e.g., the entire request-response cycle, just the controllers of a given application, just the routing, just intercepting the incoming request without needing to intercept the outgoing response, etc.) as well as different means by which to do the wrapping. It didn't seem worth going down that path, as your particular case could be handled much more simply. > 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. 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. > 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. > 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. 2. 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). 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). 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. > 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. > 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. > 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*. > I was expecting a more open perspective. > I thought offering additional, more appropriate options did reflect a fairly open perspective. 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.
