Web development with Python 3.1

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Wed Oct 28 15:10:55 CET 2009


Dotan Cohen a écrit :
>>> I have no idea what reverse url generation is.
>> It's a mean to avoid hard-coding urls in your application code - the url is
>> fully generated by the 'url mapping' system.
>>
> 
> I don't need that, see below.
> 
> 
>>> I assume that the user
>>> will call http://example.com/path/to/script.py?var1=hello&var2=world
>>>
>>> script.py would live in /home/user/site-name/public_html/path/to/
>>>
>> Now try to use apache url rewrites to use "nice urls" (like,
>> "/<section-name>/<sub-section-name>/<article-name>" instead of
>> "path/to/script-serving-articles.wtf?id=42"). Good luck.
>>
> 
> Actually, currently in the example url
> http://example.com/path/to/script.py?var1=hello&var2=world the script
> is /home/user/site-name/public_html/path/ (with no filename extension)
> and the script.py is actually page.html which is an arbitrary,
> descriptive string and not part of the script filename.

Better than the first example wrt/ SEO, but this still ties your "url 
space" to implementation AFAICT.

> 
>>> I would prefer to output everything from <html> to </html> with print
>>> statements. I don't want some framework wrapping my output in tags, I
>>> want the tags to be part of the output.
>> You're confusing the framework and the templating system. The framework by
>> itself won't wrap your "output" in anything, nor even forces you to "output"
>> HTML.
> 
> This is what I was hoping to hear. I don't remember the details, but I
> had a hard time outputting the HTML myself in Django. I will play with
> it again soon if I get the chance.
> 
> 
>> Also FWIW, it's HTTP, so we don't have "outputs", we have HTTP
>> responses.
>>
> 
> 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.  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.

> 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).

>>> Yes, why not?
>> Let's say I want to reuse your app with a different presentation. Do I have
>> to fork the whole application and send my HTML coder dig into your
>> applicative code just to rewrite the HTML parts ?
>>
> 
> No, just replace two files. In that manner it is templating. Again, an
> example from the current PHP code:
> 
> <?php
> $variables_for_header="blah";
> include "/path/to/header.inc";
> 
> // content here
> 
> include "/path/to/footer.inc";
> ?>


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...



> 
>>> Like I said before, I don't want to have to maintain the functions
>>> that turn the HTTP environment into Python variables,
>> "HTTP environment" ???
>>
>> Oh, you mean HTTP requests etc... Well, the cgi module already provides some
>> basic support here.
>>
> 
> Does it? I will look into that. I assume that basic support means
> making the cookie, GET and POST variables easily accessible.

GET and POST at least - I don't exactly remember how it works for cookies.

> 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.

> 
>>> or the code that
>>> manages database connections. Functions that escape data to be sent to
>>> MySQL (to prevent sql injection) would be nice.
>> Any DB-API compliant module already provide this - granted you use it
>> correctly.
>>
> 
> I know. This is will use correctly, I promise!
> 
> 
>>> Other than that, it's
>>> all on me.
>> Your choice...
>>
> 
> Hey! Since when am I not under attack? :)

Mmm... yes, I tend to be a bit offensive sometimes - please don't take 
it personnaly and forgive me for my lack of social skills. What I 
express are of course _my_ opinions (most of them based on experience 
but that's not the point), and I've never killed anyone for having a 
different POV - even if I'm pretty sure they are wrong !-)



More information about the Python-list mailing list