On Mon, Apr 9, 2012 at 8:28 PM, Mohd Kamal Bin Mustafa <[email protected]> wrote: > Yeah, running it with AddHandler definitely has corrupted what I'd > already understand about mod_wsgi. Also realized that php.printx() is > useless since the only way to get request data is through something > that being called from __call__() method. The idea I have in mind now > is to have __call__() parse the path_info, look for something like > /index.py/page.mako in ./htdocs, process it with mako and return the > result from mako but I guess it too silly to proceed now.
Quoting myself ... After digging through the archives I found this post by graham [1] and spent few minutes implementing his suggestion to use PATH_TRANSLATED to get the path to the mako template in ./htdocs and render it with mako in wsgi callable. Not that bad and quite interesting to proceed as weekend project. Using this approach wsgi application kind of hidden from users while mako template being promoted to the top of the stack, backward from common approach now with wsgi application (or framework) at the top and the template language somewhere down the stack. Also found another attempt to php like solution [2]. This I think almost similar to mod_perlite attempt [3], [4]. Both however kind of dead by now. [1]:http://groups.google.com/group/modwsgi/msg/3c7227c232ddc08a [2]:http://www.pyhp.org/ [3]:http://www.modperlite.org/ [4]:http://www.majordojo.com/2007/11/how-to-fix-cgi.php -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
