On Tuesday, 21 June 2016 00:20:07 UTC-4, Anthony wrote: > > However, for a programmer, the application is what is created when we >> create a new folder in the applications folder. A wrapper application has >> to be an application separated, in terms of its declaration, from the >> wrapped application. >> > > wsgihandler.py is *where* you would call the entry point to your wrapper > application (and by the way, it doesn't have to be there -- you could put > it anywhere, as long as you tell your web server where it is), but the > wrapper application code itself can be wherever you want, and it can be as > complex as you want. It would indeed be separated from the wrapped > application. > > >> we know that the wrapper as to be created as we created the wrapped >> object. >> > > Why? What are you doing that necessitates this requirement? In PHP, your > wrapper application probably doesn't look like the wrapped application, > other than that it is inside a .php file (which is also the case with WSGI > middleware, which is just Python code in .py files). > > You are right. In principle it might not have to be the exact same type of object. If it does fulfill the naive properties that I expect from a wrapper application, I should be happy to enlarge my notion of wrapper application to accept that it is not itself an ordinary application. Maybe, we should even consider a different name that "wrapper application". I have to look at what you suggest to see if it does fulfill the requirement. All the config info, including the location of the config file should be outside the folder of the wrapped application. The wrapper application should be totally controlled by the installer, I mean, it should not be needed to update it simply because we update the wrapped application. In other words, on these respects, it should be like an ordinary wrapper over a wrapped application as can be easily done with an HTTP request. I have not yet examined what you suggest. I might have questions.
> Anyway, this is one reason it helps to articulate specific use cases. > Yes and No. The original question would still hold. It would still be interesting to have the naive notion of wrapper application, which is itself an application, without HTTP request. > You make claims about how a "wrapper application" *must* look without > demonstrating *why* it must look like that. > Yes and they are not based on any use case. They are based on what seems natural. Some times, we have definitions that are just there because they are natural and we can more easily say things about them, by keeping them simple and natural. > What are the use cases that demand this particular approach? I'm not > saying web2py can easily handle all possible cases, and its execution model > probably does introduce some limitations, but it would be easier to explore > the limitations and possible workarounds with some concrete examples (the > one use case you have provided is trivially easy in web2py). > Sure, use cases are useful. They might even justify less natural definitions, but we should try to avoid them. Keeping things natural and simple is important. This in itself is a valid criteria to keep using the natural notion of a wrapper application that is also an application as any other application, if possible. -- 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.
