On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I got the part about the redirection of URLs, except how does the server know
> to use Routes instead of just trying to access the file requested by the
> browser? Is Routes the server as well?
>
> I am still lost on the concept of web servers. Each framework seems to have
> a server built-in. But are these only testing systems? What do you do when
> you want to deploy a real Python server?
>
> You spoke about controllers (for handling POST, GET, and COOKIES). Where can
> I find an explanation of what a controller is? This concept is completely
> foreign to me. In PHP, you just use the $_GET var/array and you have the GET
> data.
>
>
> Are there concepts that I need to understand about the HTTP protocol itself
> to understand some of this stuff? With PHP, you don't have to know HTTP
> details to do stuff. Is it different with Python?
What's probably lacking is an explanation of Pylons in PHP terms.
> With PHP, the concept is relatively simple to understand:
> 1. You install a web server like Apache.
> 2. You install PHP, which basically outputs text files that are then served
> to the web by Apache.
> 3. The logic of how they interact is rather simple too:
> 3a. Apache sends the GET or POST request to the PHP file and PHP has built-in
> methods for reading the GET or POST data.
> 3b. PHP then outputs text, which Apache serves up to the web for all to see.
1. You install a web server like Apache.
2. You install Pylons and a Pylons application.
2a. You make the application run continually as a system service (daemon).
2b. You configure Apache to forward all requests below a certain URL
to the Pylons application:
ProxyPass / http://localhost:5000/
3. User requests "/foo".
3a. Apache matches "/" and sends the request to Pylons *without*
looking for a file /foo.
3b. Pylons uses Routes (a Python library) to determine which method to
call, based on the URL. The method is in an application "controller"
class, of which there may be several.
3c. The controller method checks for GET/POST and reads the input
parameters, all using a framework-specific API. ("request.params" in
Pylons.)
3d. The controller method might query a database (the "model") and do
some calculations to produce result values.
3e. The controller method invokes a template. Please pay
immediately."), passing it the result values. The template returns a
complete HTML document as a string.
3f. Pylons calculates the correct HTTP headers and returns them to
Apache with the document. Apache forwards the result to the user.
(You can influence the HTTP headers via various API calls in the
controller method.)
A template is like a form letter. "Dear Mr ___: your account is
overdue by $___. Pay by ___ or we'll send the dogs after you!" A
template engine fills in the blanks, executing the template to produce
a result. Python has several template engines frequently used with
Pylons: Mako, Genshi, Myghty, Cheetah, Kid, the stan-like ones, etc.
PHP has a template engine Smarty which works similarly. PHP itself is
a template engine in a sense, and .php files are templates. However,
the term "template engine" normally means a routine whose main job is
string substitution, whereas PHP only does string substitution as a
minor part of being a programming language.
In the model-view-controller (MVC) paradigm, the model is your data.
The view is a way of looking at the data (i.e., a template). The
controller is the glue code that links the two to the current request
and performs calculations. This allows you to replace any of these
parts without changing the other parts. You may decide to use a
different database system, or a different template engine, or your
graphic designer may want to tweak the templates. Or you may decide
to port your application to another framework like TurboGears or
Quixote. If so, you can take your templates with you unchanged and
merely rewrite the controller code. You may even be able to leave the
model files mostly unchanged, depending on the differences between the
frameworks.
Redirection is a whole different concept. An external redirect means
the application sends a redirection document to the user, which makes
the browser automatically request a different URL. An internal
redirect means the framework calls a different method than the one
originally expected. Neither of these necessarily involves Routes,
although they might.
The Python web servers (Paste httpserver, CherryPy's HTTP server, FLUP
WSGI webservers) allow an application to run standalone without
Apache. Whether this is better or worse is a matter of opinion. It
partly depends on the nature of the site, ratio of static vs dynamic
content, how familiar you are with Apache modules, whether you need
SSL/virtual hosts/caching etc which *may* be easier and more reliable
under Apache, and whether your site attracts an extremely large number
of requests. The most common way to deploy Pylons is with Apache
proxying to a private Paste httpserver, so in that case you're using
both webservers simultaneously. Some people run Apache even if they
don't need to because of its supposed ability to "scrub" misformed
request -- standardize them so the application can handle them better.
--
Mike Orr <[EMAIL PROTECTED]>
_______________________________________________
Paste-users mailing list
[email protected]
http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users
