> You should perhaps look at how Python Server Pages (PSP) in mod_python
> is implemented. Documentation at:
>
> http://www.modpython.org/live/current/doc-html/pyapi-psp.html
>
> But look at mod_python source code.
yes, this is very close to the environment I'm trying to create except
for a a few minor details like having to explicitly declare separate
tags for expressions, directives, and comments. Also, the hope with
this implemented using modwsgi is that traditional wsgi apps can
coexist along side these PHP/ASP-style wsgi templates with the later
having the option to utilize wsgi middleware. I'll take a look at the
source and see what can be learned, especially how it executes the
Python code in the template.
> Your comments about 'print' show up one of the problems with a lot of
> these attempts to add Python into HTML. That is the expectation that
> 'print' output should appear in response stream.
>
> There are two approaches which people normally use for this. The first
> is to replace sys.stdout with some object which routes output back
> into response stream. The problem with replacing sys.stdout is
> ensuring it is safe in multithreaded environment. You can't just
> replace sys.stdout for life time of your request as in multithreaded
> context another request handler could do same thing and output could
> go to wrong response. You also have problems where third party module
> has used 'print' to produce debug output. Instead of going to a log
> file, that debug output will end up in response when not intended.
>
> The second approach is to compile template code and then replace
> 'print' opcode with alternate opcodes which direct output to a
> specific stream object corresponding to response. This is the better
> approach but requires more work and better done in conjunction with a
> page code caching scheme to avoid having to do it every time.
>
> A scheme which just tries to do textual substitution of 'print' in
> code before evaling/compiling it is not a good idea.
this is the approach. For code between <% %> tags, first replace
'print' with 'printwrite', then compile, then pass to eval with
'printwrite' passed to a function to append to output. Would be nice
to replace 'print' opcode after compiling but not sure how that's done
- will have to look into that. What's the issue with substituting
'print' with another keyword before compiling? Instead of
'printwrite', another long unlikely-to-be-used keyword could be
substituted if the concern is that 'printwrite' could be used in the
code somewhere for other purposes.
> Which of the above are you trying to use to ensure 'print' goes where you
> want?
>
> As to eval, ultimately somewhere the code has to be compiled and run
> and so you can't avoid evaluating it. The problem is just ensuring
> that text which comes from URL, headers or post content doesn't get
> expanded into code string before being evaluated.
this where a good example would help. The way the code is compiled
from the server-side source, I'm not clear on how text from URL,
headers or post content could manifest itself in the source code
before compilation.
> Where exactly are you using 'eval'?
as above, first 'print' is replaced with 'printwrite', then the code
is compiled, then passed to eval with optional argument of
{'printwrite': function-to-append-to-output} to add to the globals().
-Walter
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
