> > To my defense, I can say that, given that you have been proposing > alternative solutions, you could have suggested from the start that we > relax the condition that the wrapper application is a web2py application. >
I might have, but I didn't know you had that requirement until your last reply -- so my initial suggestion already *did *relax that condition. I imagine a wilder environment, but with still a lot of tools to create > applications easily. Unfortunately, it is not that I have to deal with > this kind of environments, but that I would like it to be that way. Perhaps > this kind of environment is not possible, but the concept is there anyway. > You say that nobody complained about web2py on this regard. Maybe people do > not know better. > No, I said there hasn't been demand for the concept of one application simply being able to "include" another application via a single line of code. It is related to the fact that the solution is a modification of how we > connect with an HTTP server. If I move back the code on the rocket server, > I lose the wrapper, because this modification is not implemented for this > connection. > Yes, good point. However, you could simply write a single .py file that (a) defines the WSGI application wrapper and (b) conditionally works with different web server options (including Rocket). This file could then be used on any system, regardless of the method by which the application will be served. With PHP, I do not need to change the way the connection to the server > works. I could change the web server and it would still work in the same > way. > To do this with web2py, we would have to wrap the application more directly. As already note, one way to achieve this would be to put a model file inside the application, maybe named something like __wrapper.py (the leading underscores to ensure it runs first). Any pre-processing code would go in this file. If you also need post-processing code, this file could set response._caller, which will wrap whichever controller action gets called. It would be easy to do updates in a way that avoids overwriting this file. I know this isn't your ideal solution, but I think the best we could do (without writing some complicated helpers). I think the issue here is that web2py is tightly coupled with the web > server and there is no way to get the modularity that I expect. It is the > way with python, perhaps. > web2py is not tightly coupled with the web server, it just doesn't happen to provide an easy way to do request pre/post processing without (a) wrapping the framework's WSGI application or (b) including some code in the application folder. This is generally not a problem outside of your somewhat contrived scenario where the web2py installation and the application code are under the control of two different parties who apparently are not able to coordinate a consistent set of standards or update mechanisms between each other. If this becomes a common scenario among web2py users, I assume someone will come up with a workable solution. I don't think it is a common scenario, though, so the current mechanisms for "wrapping" seem adequate. Also, I got confused by the fact web2py handles the HTTP requests via a > single function gluon.main.wsgibase, which deals with the pathinfo. In the > case of PHP, I can have different wrappers (in different files) for > different requests, because distinct requests are mapped to distinct files. > First, note that web2py's wsgibase function is just a starting point to receive requests -- from there each request is routed to the appropriate application, controller, and function. It works the same way with PHP, though in some cases, the web server itself does the routing to individual PHP files (that is the case you describe). However, in a more complex PHP application built with a web framework comparable to web2py, the framework itself will likely do the routing, and rather than having a separate .php file for each page/route, the code will likely follow something like an MVC structure, just like web2py. Second, as noted earlier, the WSGI wrapper can be as complex as you like. It can inspect the incoming request and do whatever pre-processing you want depending on the particular route requested. Third, if you wrap individual PHP files (each associated with some URL route), you are not wrapping an application, but simply wrapping individual actions. Of course, you can directly wrap individual web2py actions as well. If we want, the wrapped application can be requested directly, without > modifying any code. > If using WSGI middleware, you could do the same in web2py by conditionally doing the pre/post processing depending on the URL. You would have to do something similar if using a PHP framework. The fact that we do not have this here created the feeling that this > wrapper is not really a separate application from the wrapped object, which > in this case is web2py. > Right, the wrapper is not a standalone application -- its purpose is to do some pre/post processing. It would be the same in PHP (i.e., the wrapper wouldn't be generating web pages on its own without actually wrapping an application). Anyway, a full-stack MVC web framework like web2py is not really comparable to some simple PHP scripts served via Apache. If you want a more relevant comparison to the PHP world, you should spend some time with one of the popular PHP frameworks. 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.
