It is also important that the installer does not have to use the application folder.
On Thursday, 23 June 2016 10:23:45 UTC-4, Anthony wrote: The installer creates the /applications/myapp folder and puts a single > __wrapper.py file inside the /models folder ... > The simple fact that the author of the application does not need to know >> where is located the configuration information is very nice and it can >> become important. >> > > I think you misunderstand the proposed solution. It does "wrap" the > application code in the sense that it executes code both before and after > the application itself processes a request, and the application author > indeed does not need to know the location of the configuration information. > Not at all. Yes, I did put some emphasis on one requirement, the one that says that the author does not have to know the location of the configuration info (and thus would not use the application folder for that purpose,) but the use case that justifies the wrapper also includes the requirement that the installer does not use the application folder. Sure, someone might only want to fulfill the first requirement. I am not going to argue that this requirement is not important in itself and that it is not nice that your proposal fulfills it. 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 it is outside the wrapped application. I think it makes sense to do that. A wrapper that is inside the wrapped object is not what we consider a wrapper. Yes, I agreed that 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. > >> By the way, this process is exactly identical to the plugin proposal >>> (though without using the strict naming conventions of the plugin system, >>> which would complicate things unnecessarily). You could view either the >>> wrapper or the wrapped application (or both) as a plugin (a plugin is just >>> any subset of an application). >>> >> >> I am surprised that in the plugin approach the application wrapper is >> inside the plugin, which is the wrapped application. I must have >> misunderstood what is the the plugin approach. >> > > That's not quite the right way to think of it. Nothing is "inside" of > anything here -- the actual code files are side by side in the same > application folder. The distinction is that the "wrapper" code is in a > separate file from the rest of the application (though in the same folder) > that runs before and after the rest of the application code. So the wrapper > is very much a "wrapper application" -- it's just that at least one of its > files must reside in the application folder (it can import modules that are > outside the application folder). > I completely disagree. I do understand why you can think that way. Yes, there is something interesting achieved by your __wrapper.py proposal and it can be done as you describe in the application folder. I might have missed the importance of this fact and helped to the confusion when I put the emphasis on only one requirement. Because of that, you created a definition of application wrapper that allows it to be within the same folder as the application itself. It almost fulfills the requirements : the author does not have to worry about the location of the configuration information and the configuration information is passed by what you call the "wrapper". 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. This requirement stands by itself. So, it's natural that in the definition of an application wrapper, we require that it is not in the same folder as the wrapped application. I know that you say that this specific requirement is not important, perhaps because you rightly see that it is already interesting without it. So, fine, we have two concepts. The concept where we are happy with only the requirement that the author does not need to know the location of the configuration information and the concept where, in addition, we require that the wrapper is separated from the application folder. Concepts are important and in that cases it would make no sense at all to say that one is more important than the other. This is not the way it works. Take the concept of the number 0. One could say it's not important because in my use cases I never have 0 things and the concept of "1" is more important. This would be ridiculous. In the same way, I think the existence of these two concepts, with or without the extra requirement, help each others. For example, we can ask the question, why once we have achieved the requirement of the first concept, it is not very easy to achieve the extra requirement of the second concept? Specifically, in your case, why it is not easy to move the wrapper outside the folder? If it is not easy, is there some fundamental explanation related to the web2py architecture? There is something that I realize now. The true property that we want or I want is not that the installer does not use the application folder. I am all for freedom and no control. If in a scenario, the installer uses the application folder and it works, it's perfect. So, I am not saying that your proposal is not nice. The true property that we want is that the installer does not have to use the application folder, if he does not want to. So, it is a requirement for more flexibility. > > >> Note, something like the above is only really necessary if you assume you >>> have to wrap arbitrary applications and that there can be no coordination >>> or cooperation between the installer and the application developer. >>> >> >> In that scenario, I believe that you need a real wrapper in its own >> separated space, not a wrapper inside the wrapped application. >> > > It depends. Assuming the installer has control over the web2py folder, the > proposed solution works. The only time it wouldn't work is if the > application author has complete control over the /applications/app folder > and the installer cannot touch that folder (probably a rare situation). > > >> Without those constraints, we could instead simply provide an API to the >>> application developer, and the application could be responsible for >>> importing from a special "wrapper" module in order to set up the code >>> necessary to do the wrapping. >>> >> >> Without those constraints, it depends on what are the other constraints, >> if any. >> > > Those are the only relevant constraints. Without constraints limiting > coordination between the installer and application developer, we are free > to implement an API to be used by the application developer. > > >> If the installer can use some space within the application folder, he can >> simply use that space to directly provide the location of the configuration >> file. For example, if he can use that space for __wrapper.py, then he could >> as well use that space to directly store the the location of the >> configuration file. >> > > Well, yes, that's the exact purpose of __wrapper.py -- assuming the > pre-processing required for this particular application is to provide some > configuration data, you would put that data (or the location of a file > containing it) in __wrapper.py. What else did you think __wrapper.py was > for? > > Well, if the author does not have to know the location of the configuration information, then you must be doing something slightly more complicated than what I have in mind. 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. > Anyway, we appear to be going in circles. > I am sorry for you if you feel that you went into circles and I certainly do not want to continue having you feel that way. However, even in these last posts, on my side, I don't feel I went into any circle. This clarification of the distinction between two closely related concepts was not part of any circle. > I believe we have well articulated the various possibilities available > with web2py. At this point, I suggest you spend some more time learning > web2py and how it works and then just start coding. As you work on > implementing your solution, come back with specific questions if you run > into problems. > Well thank you for the offer. It is appreciated. I am using web2py as a learning tool. That does not mean that I do not code with it, of course I code with it. However, thus far, when I had questions about specific coding issues, some bug there, how do we debug, how do we do that, etc, I tried to be self sufficient, even it meant searching a lot, looking at the code, etc. By the way, the documentation is very good. However, this kind of discussions as we just had, I cannot have in a self sufficient manner. I appreciate that very much. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
