Dotan Cohen a écrit :
Clearly. I was referring to stdout being send to the browser as the
http response.
s/browser/web server/ - it's the web server that reads your app's stdout and
send it (as is or not FWIW) back to the client.
As is, in my case. Actually, what use case is there for having Apache
reprocess the HTML output of the script?
compression, cache, whatever...
And this "output to stdout"
thingie is just the ipc scheme used for CGI - there are other possible
interfaces between the application code and the web server.
Other possible interfaces between the application code and the web
server?
Depends on the web server, obviously. With Apache you have things like
mod_python, mod_wsgi, or mod_php if you go that route.
FWIW, while I would not necessarily advise using mod_python (unless of
course you really need deep Apache integration instead of independance
from the frontal web server), reading the mod_python's manual might
teach you a lot about the processing of a HTTP request and what you can
do...
>
I think I mentioned that, but I apologize for being
unclear.
It's not that it was unclear, but that it's innaccurate. "outputting to
stdout" is an implementation detail, and should not be exposed at the
applicative code level. Dealing with appropriate abstraction - here, an
HttpResponse object - is far better (well, IMHO of course... - standard
disclaimers, YMMV etc).
I see. I believe that is called Dotan's Razor: a slight inaccuracy
saves a lengthy explanation.
but also impacts your "mental map" of what's going on... You're thinking
in terms of streams and stdout, which, while not that far from actual
implementation (in the end it always boils down to bits sent over the
wires...), might not be the right level of abstraction when it comes to
application programming.
Sorry, but all I can "replace" here are the header and footer - if I want to
generate a different markup for the "content here" part, I have to modify
your applicative code. I've written web apps that way myself (some 7 years
ago), and still have to maintain some web apps written that way, you know...
Quite so, I though that is what you wanted. Yes, the HTML is
hard-coded into the script. I am learning to abstract and even use
object-oriented approaches, though.
You can have efficient abstraction and decoupling without resorting to
OO. Also, remember that PHP is first a templating language...
I google,
but cannot find any exapmles of this online.
Well, no one in it's own mind would still use CGI (except perhaps for very
trivial stuff) when you have way better solutions.
What I am doing _is_ trivial.
What I saw is already complex enough to justify using better tools IMHO.
Or to make better use of the one you have.
I understand that your goal is to
help me. I am a hard learner: I recognize that you are teaching me the
better way, but I need convincing as to why it is better. "Bruno said
so" is good,
It isn't.
but "saves you coding time down the line" is a lot more
convincing!
Well, my POV is obviously biased - I've been doing mostly web
programming for 6 or 7 years now, and not as a hobby. When you have
several new projects to ship within a short timeline while still
maintaining older projects, you really start thinking hard about
readability, maintainability, and possible reuse. But wrt/ hard-coded
embedded HTML vs templating (even in it's simpler form), it's not a
matter of "bruno said so" - it's a well-known antipattern.
--
http://mail.python.org/mailman/listinfo/python-list
