On Thursday, 23 June 2016 00:14:36 UTC-4, Anthony wrote: > > > 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. What is important is very relative. One may try to show the importance with a use case, but it will be relative to the importance of the use case. How do you show the importance of the use case? It gets very complicated. Use cases are useful to give a context, to explain how some code can be used, and, above all, to express what we expect from some code, not to show that the code is important.
Some requirements are of immediate importance while others are more fundamentals. It is hard to compare oranges and apples. The requirement to use application wrappers is in the fundamental category. It's difficult to rigorously show its importance. One would need to develop a new approach to develop and reuse code, etc. and show how this requirement helps. Until someone has developed such an approach, we have no solid argument, but I do believe it is a nice approach. 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. It is certainly important as a concept and concepts are very 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 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. > > 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. > 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. 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. -- 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.
