Web development with Python 3.1

[Bruno Desthuilliers]

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.