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 !-)
--
http://mail.python.org/mailman/listinfo/python-list
