You should write a self-contained document to explain your concept of wrapper application. In this post, you try to explain the concept of application wrapper (at the application level) in opposition to the concept of a wrapper at the framework level. You say that I do not understand this concept and I agree that it is not the concept that I had in mind. Your concept is different because the use case is not to pass the configuration information, but the need for a wrapper (for pre-processing and post-processing) and it does not have the extra requirement that the wrapper should not need the application folder. So, it's sufficiently different that we should not mix both. In the beginning, you said that it was not well defined and I should give up on this. Now, you are trying to explain it to me. I read your explanation and I can see that you got interested in the concept of wrapper application, but in your own way. So, my definition of wrapper application is not so interesting for you: you feel the extra requirement is not necessary or, to use your own word, not important. I am begging you to forget about important vs unimportant, making the very valid point that all concepts are important, but instead of trying to understand the concept, you move ahead with your own concept. It may be the case that my concept triggered a different concept in you, without this extra constraint, which maybe interesting on its own.
Here is what happened. You illustrated your concept with the __wrapper.py example. I did not try to evaluate your concept in terms of your use case or goal, which was to provide a wrapper for pre-processing and post-processing. I tried to make a point in terms of the use case that I stated originally, which was a need to pass the config information under severe constraints. I never claimed that I had a different way to do a wrapper application that fulfill your goal. I was not with you at all in this way of thinking. I was still trying to discuss in terms of my use case. I was just stating that, given that the goal is to pass the configuration information, and we have access to the application folder, we have a simpler way. I know that you provided your own way, with the os variables, etc. One of them was perhaps a more standard way to implement the same idea. Still, my point is that, from my perspective, with the use case that I had in mind, your example was an overkill, perhaps not an overkill for your goal, but an overkill for the goal in the use case that I presented. Moreover, it did not fulfill the extra requirement that you say is unimportant. *No concept is unimportant. * In particular I come back to one question that I asked using that concept, which I feel you never answered. Starting with your __wrapper.py example, can you explain why it is difficult, if it is difficult, to satisfy the extra requirement that I have in my use case. How is this related to the architecture of web2py. The more interesting question is, in general, why is it difficult to satisfy this extra requirement in web2py. Trust me, it is easy with PHP. It's obvious, I have done it with wordpress, it's trivial, you simply include the index.php file of the wordpress folder, after having changed the current working directory accordingly. It works and it could not fail. PHP is built so that it works. If you only answer is that it is not important and you say that I should provide a real world use case, then we are done. I already explained that interesting use cases can be abstract. The more the goal has a large scope, the more the use cases are abstract. The most abstract use cases is to cover all possible use cases, even those that hard to predict. This is the best abstract use case, the ultimate one to try to fulfill. If you don't get it, I would say that you are stubborn and I would be also stubborn, if I insisted. I am sincere when I say that you should write a self-contained document, taking care of not mixing it with my stuff. The point is that, if I have my stuff in mind, I would get frustrated. On the other hand, you put so much time in this discussion that I owe you to understand what you want to explain, but it will need to be separated from my stuff. On Thursday, 23 June 2016 22:50:38 UTC-4, Anthony wrote: > > > 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). >>> >>> >> >> In what I have in mind, the installer has no code to write. He passes the >> info by creating a file path/to/location.ini >> , which contains >> >> configFileLocation = /path/to/config/file >> >> The author uses configparser to read the file and get the location of the >> config file: >> >> config = configparser.ConfigParser() >> config.read(['path/to/location.ini']) >> >> It's simple and there is no wrapper, but we see the location >> path/to/location.ini in the code written by the author. This means that >> the author needs to know the location. Had I used a wrapper, the author >> would not need to know any location to obtain the location of the config >> file. The code would read the passed value, say in request.env. The >> situation is fundamentally different in the simple solution with no >> wrapper, because the code needs to know one location to learn another >> location. I am not sure why I explain this, because I think we already >> share this kind of understanding. So, I was just saying, if the installer >> can use a file in the application folder, why not use this simple solution >> that needs no wrapper. >> > > This seems nonsensical. Why make the application know the path to one > configuration file just to learn the path to another? Anyway, this is not > what I asked you to do. You made the claim that if the installer has access > to the application folder, the installer could do something to provide > information to the application that was not equivalent to my proposal of > the __wrapper.py file. I contest that claim and request that you write the > code that you claim is different. Your example above does not do this, as > it involves no code written by the installer in the application folder. I > don't understand why you have written the code that you have or what point > you are trying to make with it, but it has nothing to do with anything I > was saying. > > Also, note that the idea of putting "wrapper" code inside the application > folder is a more general solution for when you need to do real pre (and > possibly post) processing. I would *not* suggest using that method merely > to communicate the location of a configuration file (as in your example > above), as very early in this discussion I proposed several simpler > alternatives. > > Anyway, don't worry about it -- it seems unlikely we're going to > straighten this out. > > >> 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. >>> >>> >> >> Yes, but this is not the part that we discuss. >> > > No, it is exactly what was under discussion. Here is your exact quote to > which my above paragraph is a response: > > *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. 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.* > > You were clearly claiming that I misunderstood your requirement to have > the wrapper reside outside of the application folder. > > >> Just want to make sure we understand each other. I agree that we are >> doing great, but there was this point. Also, I still do not agree about >> the "unimportant". I suspect you meant not important for someone that uses >> web2py in a real practical scenario. However, this is the thing that is not >> important for someone that is interested in creating a different framework. >> > > I understand that you disagree about the importance of the nature of the > wrapping that you propose. Yet you have still made no argument whatsoever > about why it is important, other than simply to state that it is > self-evident. So, I think we understand each other. > > 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. >>> >> >> I thought we agreed that it was possible at the application level using >> middleware. The initial code that handle the requests, which is a kind of >> wrapper, needs only to map these requests to different application wrappers >> in view of the application. These wrappers will then call >> gluon.main.wsgibase as usual. This does not seem so complicated. >> > > That still does not wrap the code at the application level. Wrapping at > the application level means executing code in the same web2py environment > where the application code is executed (so, for example, you can access and > manipulate the same web2py request object that gets passed to the > application itself). Using WSGI middleware, you are wrapping at the > framework level in the sense that you can only intercept the incoming WSGI > environment (before the web2py framework does anything with it) and the > outgoing WSGI string/iterable response (after web2py has serialized the > response object). > > >> 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), >>> >> >> I agreed that this is not useful. I am happy with a wrapper that is not a >> web2py application. >> > > But you weren't quite happy with the way to achieve that in web2py, which > requires manipulating the various handlers used with different web servers > (or forking the framework). The only way to avoid that is to wrap at the > application level via a file in the application folder, which you also > don't like, leaving something like the third (non-existent) option above. > But if you say you are happy with the available options, great. > > >> 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*. >>> >> >> Sure, but we extract requirements from use cases. This is the common >> notion of use cases. >> > > Yes, that is my exact point. But just because *some* requirements are > extracted from use cases does not mean *all *requirements come from use > cases. > > A use case implies a real world scenario where the requirement is really a >>> requirement. >>> >> >> That would make use cases only useful to state requirements in systems >> that currently exist in the real world. It is not the commonly accepted >> notion of use cases. It is important to do that, but it is not enough. We >> need also (abstract) use cases to define where we want to go in the future. >> Typically, use cases for future developments are abstract. >> > > I did not argue that a use case must currently exist, only that we > shouldn't necessarily strain ourselves to meet random requirements unless > we think we will have some *use* for them (now or in the future). Of > course, if it is trivially easy to provide some extra flexibility by > meeting a particular requirement, go for it. > > But note that this is all in the context of web2py. Doing *exactly* what > you want is not quite possible out of the box. I'm just arguing that in the > context of web2py, doing *exactly* what you want also isn't that > important, as we can implement alternative solutions that should meet all > your needs. In other words, in the context of web2py, it wouldn't be worth > making any great efforts to get exactly what you want, because those > efforts would buy you very little. > > >> 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. >>> >> >> Why do you assume that I am wrong? Maybe you don't grasp what I have in >> mind. >> > > I've explained it multiple times. If you'd like to discuss the above issue > any further, please show some code. > > Basically, you are saying implement the solution in each case. It's fine, >> just thought that maybe there was more. I might prefer to implement your >> proposal by hacking the core. I rename gluon.main.wsgibase to >> gluon.main.wsgibase_wrapped and then gluon.main.wsgibase becomes the >> wrapper, In this way, it works for all servers, no need to implement the >> solution for each server. >> > > Sure, but it's generally not a good idea to fork the framework (you might > break something important, and then you have to bother with merging all > future changes, or give up on upgrading in the future). In fact, as long as > you're going to fork the framework, using WSGI middleware is probably not > the simplest option. Instead, you could probably hack gluon.main.wsgibase > directly to wrap applications at a higher level (i.e., within the web2py > environment). > > Anthony > > On Thursday, 23 June 2016 22:50:38 UTC-4, Anthony wrote: > > > 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). >>> >>> >> >> In what I have in mind, the installer has no code to write. He passes the >> info by creating a file path/to/location.ini >> , which contains >> >> configFileLocation = /path/to/config/file >> >> The author uses configparser to read the file and get the location of the >> config file: >> >> config = configparser.ConfigParser() >> config.read(['path/to/location.ini']) >> >> It's simple and there is no wrapper, but we see the location >> path/to/location.ini in the code written by the author. This means that >> the author needs to know the location. Had I used a wrapper, the author >> would not need to know any location to obtain the location of the config >> file. The code would read the passed value, say in request.env. The >> situation is fundamentally different in the simple solution with no >> wrapper, because the code needs to know one location to learn another >> location. I am not sure why I explain this, because I think we already >> share this kind of understanding. So, I was just saying, if the installer >> can use a file in the application folder, why not use this simple solution >> that needs no wrapper. >> > > This seems nonsensical. Why make the application know the path to one > configuration file just to learn the path to another? Anyway, this is not > what I asked you to do. You made the claim that if the installer has access > to the application folder, the installer could do something to provide > information to the application that was not equivalent to my proposal of > the __wrapper.py file. I contest that claim and request that you write the > code that you claim is different. Your example above does not do this, as > it involves no code written by the installer in the application folder. I > don't understand why you have written the code that you have or what point > you are trying to make with it, but it has nothing to do with anything I > was saying. > > Also, note that the idea of putting "wrapper" code inside the application > folder is a more general solution for when you need to do real pre (and > possibly post) processing. I would *not* suggest using that method merely > to communicate the location of a configuration file (as in your example > above), as very early in this discussion I proposed several simpler > alternatives. > > Anyway, don't worry about it -- it seems unlikely we're going to > straighten this out. > > >> 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. >>> >>> >> >> Yes, but this is not the part that we discuss. >> > > No, it is exactly what was under discussion. Here is your exact quote to > which my above paragraph is a response: > > *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. 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.* > > You were clearly claiming that I misunderstood your requirement to have > the wrapper reside outside of the application folder. > > >> Just want to make sure we understand each other. I agree that we are >> doing great, but there was this point. Also, I still do not agree about >> the "unimportant". I suspect you meant not important for someone that uses >> web2py in a real practical scenario. However, this is the thing that is not >> important for someone that is interested in creating a different framework. >> > > I understand that you disagree about the importance of the nature of the > wrapping that you propose. Yet you have still made no argument whatsoever > about why it is important, other than simply to state that it is > self-evident. So, I think we understand each other. > > 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. >>> >> >> I thought we agreed that it was possible at the application level using >> middleware. The initial code that handle the requests, which is a kind of >> wrapper, needs only to map these requests to different application wrappers >> in view of the application. These wrappers will then call >> gluon.main.wsgibase as usual. This does not seem so complicated. >> > > That still does not wrap the code at the application level. Wrapping at > the application level means executing code in the same web2py environment > where the application code is executed (so, for example, you can access and > manipulate the same web2py request object that gets passed to the > application itself). Using WSGI middleware, you are wrapping at the > framework level in the sense that you can only intercept the incoming WSGI > environment (before the web2py framework does anything with it) and the > outgoing WSGI string/iterable response (after web2py has serialized the > response object). > > >> 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), >>> >> >> I agreed that this is not useful. I am happy with a wrapper that is not a >> web2py application. >> > > But you weren't quite happy with the way to achieve that in web2py, which > requires manipulating the various handlers used with different web servers > (or forking the framework). The only way to avoid that is to wrap at the > application level via a file in the application folder, which you also > don't like, leaving something like the third (non-existent) option above. > But if you say you are happy with the available options, great. > > >> 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*. >>> >> >> Sure, but we extract requirements from use cases. This is the common >> notion of use cases. >> > > Yes, that is my exact point. But just because *some* requirements are > extracted from use cases does not mean *all *requirements come from use > cases. > > A use case implies a real world scenario where the requirement is really a >>> requirement. >>> >> >> That would make use cases only useful to state requirements in systems >> that currently exist in the real world. It is not the commonly accepted >> notion of use cases. It is important to do that, but it is not enough. We >> need also (abstract) use cases to define where we want to go in the future. >> Typically, use cases for future developments are abstract. >> > > I did not argue that a use case must currently exist, only that we > shouldn't necessarily strain ourselves to meet random requirements unless > we think we will have some *use* for them (now or in the future). Of > course, if it is trivially easy to provide some extra flexibility by > meeting a particular requirement, go for it. > > But note that this is all in the context of web2py. Doing *exactly* what > you want is not quite possible out of the box. I'm just arguing that in the > context of web2py, doing *exactly* what you want also isn't that > important, as we can implement alternative solutions that should meet all > your needs. In other words, in the context of web2py, it wouldn't be worth > making any great efforts to get exactly what you want, because those > efforts would buy you very little. > > >> 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. >>> >> >> Why do you assume that I am wrong? Maybe you don't grasp what I have in >> mind. >> > > I've explained it multiple times. If you'd like to discuss the above issue > any further, please show some code. > > Basically, you are saying implement the solution in each case. It's fine, >> just thought that maybe there was more. I might prefer to implement your >> proposal by hacking the core. I rename gluon.main.wsgibase to >> gluon.main.wsgibase_wrapped and then gluon.main.wsgibase becomes the >> wrapper, In this way, it works for all servers, no need to implement the >> solution for each server. >> > > Sure, but it's generally not a good idea to fork the framework (you might > break something important, and then you have to bother with merging all > future changes, or give up on upgrading in the future). In fact, as long as > you're going to fork the framework, using WSGI middleware is probably not > the simplest option. Instead, you could probably hack gluon.main.wsgibase > directly to wrap applications at a higher level (i.e., within the web2py > environment). > > 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.
