On Thursday, June 23, 2016 at 1:26:38 PM UTC-4, Dominic Mayers wrote: > > It is also important that the installer does not have to use the > application folder. >
Unless you can identify common scenarios in which there is an installer who is responsible for setting up web2py but somehow does not have access to the application folder, I disagree that this is important. > However, if your objective is to be able to pass the configuration > information and the installer can use the application folder, I don't see > why they would not use it to achieve this objective, no need for a wrapper. > So, I include in the definition of an application wrapper the requirement > that the installer does not need to edit the application folder. I think > it makes sense to do that. > I think the problem is that you are thinking too abstractly without considering what the actual code would look like. If you think about the code, you would realize that what you say above makes no sense. I leave the following to you as an exercise: assume the installer has access to the application folder and wants to "pass the configuration information" to the application. Please write the actual code to do that. Whatever code you write, that is exactly what I call the "wrapper" (as the code must run before the rest of the application, making available the relevant data in some object available to the application). > Perhaps the confusion is that I agreed that the wrapper does not have to > be a web2py application, but this is different. The wrapper does not have > to be a web2py application, but the wrapped object must be the folder that > contains the controller, the views, the models, etc. designed by the author. > No, there is no confusion. This is where you go in circles. I have explicitly acknowledge multiple times that I know your ideal solution involves the "wrapper" code being outside the application folder, and I proposed the WSGI middleware solution as the closest you can get to what you want. I *separately* offered the idea of a "wrapper" file *inside* the application as a reasonable alternative that would work in almost any conceivable circumstance. If you somehow encounter a scenario where that won't work, of course, don't use it. > The whole idea here is to have a clean separation between the wrapper and > the wrapped application. I believe that you might have misunderstood the > concept and perhaps you are going to give up, but it does not mean the > concept is not important. > At this point, it is not clear what you hope to achieve with further discussion. If you want to wrap at the application level, the best you can do is put the wrapper code inside the application folder. If you are willing to wrap at the framework level, you can use WSGI middleware. If you want to somehow write two separate web2py applications, one of which transparently "wraps" the other (without requiring any cooperation from the wrapped application and without redirects), then you would have to write some very specialized code to achieve that (and it might be difficult to ensure all edge cases are well handled). The *exact* thing you are asking for, therefore, simply isn't available out of the box. You can continue going on about how important it is, but that won't summon it into existence. So, what are you trying to accomplish here? > However, just step back a bit. There is a use case, which was used to > define the concept of application wrapper. It's important that this > definition takes into account all requirements of the use case. One of the > requirements is that the installer does not use the application folder. > A *requirement* is different from a *use case*. A use case implies a real world scenario where the requirement is really a requirement. You have not described a real world situation in which someone who is responsible for setting up the framework does not have access to the application folder. But again, even if there is such a case, we are still left with the options previously articulated -- so, choose one and move on. > Specifically, in your case, why it is not easy to have a wrapper where > the installer does not need to use the application folder? If it is not > easy, is there some fundamental explanation related to the web2py > architecture? > Yes, this has already been explained. But as I said, if you would like to explore these ideas further, I suggest you spend more time learning web2py, maybe study some of its source code. Try building what you want and see what you end up with. > What I have in mind is that the code of the application directly reads > this location, which is under the control of the installer and by looking > at the code you know the location relative to the application folder. This > is not what happens when the information is passed by a wrapper. So, you > must have an intermediary "wrapper" in your proposal. > Again, take some time and write the code. Hopefully that will help you see where you are going wrong here. > Perhaps what you are saying is that you only care about the concrete > proposals in terms of code and you don't feel the concepts are important. > Therefore, as long as you do not see any progress in terms of proposals, > actual code, you feel you are turning into circles. That would be OK. I > would consider this as a rule, at the least with you. > I have no such rule and think I have demonstrated I am happy to discuss concepts. However, I think we have covered everything conceptually, and you should now be aware of the various implementation possibilities. So all this is left to do is actually implement the solution you seek. > I might still have a question regarding code. How do you make sure that > the edit of wsgihandler.py, without hacking the names for > gluon.main.wsgibase, is seen irrespective of the web server? > Well, any deployment setup will ultimately require providing a WSGI application. So, just write a WSGI compliant callable (which itself will ultimately call gluon.main.wsgibase), and make sure you point the web server to that callable by whatever means are appropriate for the particular web server. The logging option in wsgihandler.py using gluon.main.appfactory is an example of this approach, so study that as a starting point. 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.
