> Regarding the comment that the flexibility to have a separate wrapper is >>> not important, >>> >> >> Unimportant for the wrapper code to be outside the application folder >> because there is a simple approach that should work fine. The installer >> creates the /applications/myapp folder and puts a single __wrapper.py file >> inside the /models folder. The content of this wrapper file would be >> sufficient to handle pre-processing of the request as well as >> post-processing of the response. The application developer would send the >> application to the installer, and it would simply be unpacked on top of the >> /myapp folder, leaving the __wrapper.py file in place (alternatively, the >> __wrapper.py file cold be copied in after). >> >> > It is not because you have a proposal that fails to respect the > requirement that the requirement is unimportant. >
Right, I didn't say the requirement was unimportant just because we can't meet it. It is unimportant because it is unnecessary in most cases. > The requirement to use application wrappers is in the fundamental > category. > Not sure what that means. If you think something is important, you should be able to explain *why* rather than merely stating that it is self-evident. > 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. > 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). > 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? Anyway, we appear to be going in circles. 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. 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.
