web框架前戲---web框架的本質

Web框架本質

 

1. *瀏覽器發送一個HTTP請求；
2. *服務器收到請求，生成一個HTML文檔（待補充；是不是所有類型的訪問都須要生成文檔）；
3. *服務器把HTML文檔做爲HTTP響應的Body發送給瀏覽器；
4. *瀏覽器收到HTTP響應，從HTTP Body取出HTML文檔並解析顯示

　　對於全部的Web應用，本質上其實就是一個socket服務端，用戶的瀏覽器其實就是一個socket客戶端。（即BS架構）

　　靜態頁面--最簡單的Web應用就是先把HTML用文件保存好，用一個現成的HTTP服務器軟件，接收用戶請求，從文件中讀取HTML，返回。

　　若是要動態生成HTML，就須要把上述步驟本身來實現。不過，接受HTTP請求、解析HTTP請求、發送HTTP響應都是苦力活，若是咱們本身來寫這些底層代碼，還沒開始寫動態HTML呢，就得花個把月去讀HTTP規範。正確的作法是底層代碼由專門的服務器軟件實現，咱們用Python專一於生成HTML文檔。由於咱們不但願接觸到TCP鏈接、HTTP原始請求和響應格式，因此，須要一個統一的接口，讓咱們專心用Python編寫Web業務。

　　這個接口就是WSGI：Web Server Gateway Interface。

#!/usr/bin/env python
#coding:utf-8
 
import socket
 
def handle_request(client):
    buf = client.recv(1024)
    client.send("HTTP/1.1 200 OK\r\n\r\n")
    client.send("Hello, Seven")
 
def main():
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.bind(('localhost',8000))
    sock.listen(5)
 
    while True:
        connection, address = sock.accept()
        handle_request(connection)
        connection.close()
 
if __name__ == '__main__':
    main()

上述經過socket來實現了其本質，而對於真實開發中的python web程序來講，通常會分爲兩部分：服務器程序和應用程序。服務器程序負責對socket服務器進行封裝，並在請求到來時，對請求的各類數據進行整理。應用程序則負責具體的邏輯處理。爲了方便應用程序的開發，就出現了衆多的Web框架，例如：Django、Flask、web.py 等。不一樣的框架有不一樣的開發方式，可是不管如何，開發出的應用程序都要和服務器程序配合，才能爲用戶提供服務。這樣，服務器程序就須要爲不一樣的框架提供不一樣的支持。這樣混亂的局面不管對於服務器仍是框架，都是很差的。對服務器來講，須要支持各類不一樣框架，對框架來講，只有支持它的服務器才能被開發出的應用使用。這時候，標準化就變得尤其重要。咱們能夠設立一個標準，只要服務器程序支持這個標準，框架也支持這個標準，那麼他們就能夠配合使用。一旦標準肯定，雙方各自實現。這樣，服務器能夠支持更多支持標準的框架，框架也可使用更多支持標準的服務器。

WSGI（Web Server Gateway Interface）是一種規範，它定義了使用python編寫的web app與web server之間接口格式，實現web app與web server間的解耦。

python標準庫提供的獨立WSGI服務器稱爲wsgiref。

from wsgiref.simple_server import make_server


def RunServer(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    return [bytes('<h1>Hello, web!</h1>', encoding='utf-8'), ]


if __name__ == '__main__':
    httpd = make_server('', 8000, RunServer)
    print("Serving HTTP on port 8000...")
    httpd.serve_forever()

WSGI 簡單介紹

　　WSGI，全稱 Web Server Gateway Interface，或者 Python Web Server Gateway Interface ，是爲 Python 語言定義的 Web 服務器和 Web 應用程序或框架之間的一種簡單而通用的接口。自從 WSGI 被開發出來之後，許多其它語言中也出現了相似接口。

　　WSGI 是做爲 Web 服務器與 Web 應用程序或應用框架之間的一種低級別的，以提高可移植 Web 應用開發的共同點。WSGI 是基於現存的 CGI 標準而設計的。

　　不少框架都自帶了 WSGI server ，好比 Flask，webpy，Django、CherryPy等等。固然性能都很差，自帶的 web server 更多的是測試用途，發佈時則使用生產環境的 WSGI server或者是聯合 nginx 作 uwsgi。

　　通俗來說，WSGI就像是一座橋樑，一邊連着web服務器，另外一邊連着用戶的應用。可是呢，這個橋的功能很弱，有時候還須要別的橋來幫忙才能進行處理。

WSGI的做用

　　WSGI有兩方：「服務器」或「網關」一方，以及「應用程序」或「應用框架」一方。服務方調用應用方，提供環境信息，以及一個回調函數（提供給應用程序用來將消息頭傳遞給服務器方），並接收Web內容做爲返回值。

　　所謂的 WSGI中間件同時實現了API的兩方，所以能夠在WSGI服務和WSGI應用之間起調解做用：從WSGI服務器的角度來講，中間件扮演應用程序，而從應用程序的角度來講，中間件扮演服務器。「中間件」組件能夠執行如下功能：

• 重寫環境變量後，根據目標URL，將請求消息路由到不一樣的應用對象。
• 容許在一個進程中同時運行多個應用程序或應用框架。
• 負載均衡和遠程處理，經過在網絡上轉發請求和響應消息。
• 進行內容後處理，例如應用XSLT樣式表。

　　WSGI 的設計確實參考了 Java 的 servlet。http://www.python.org/dev/peps/pep-0333/ 有這麼一段話：

By contrast, although Java has just as many web application frameworks available, Java’s 「servlet」 API makes it possible for applications written with any Java web application framework to run in any web server that supports the servlet API.

　　另外，須要說起的一點是：其它基於python的web框架，如tornado、flask、webpy都是在這個範圍內進行增刪裁剪的。例如tornado用的是本身的異步非阻塞「wsgi」，flask則只提供了最精簡和基本的框架。Django則是直接使用了WSGI，並實現了大部分功能。

自定義Web框架

1、框架

經過python標準庫提供的wsgiref模塊開發一個本身的Web框架

#!/usr/bin/env python
#coding:utf-8
from wsgiref.simple_server import make_server

def index():
    return 'index'

def login():
    return 'login'

def routers():
    
    urlpatterns = (
        ('/index/',index),
        ('/login/',login),
    )
    
    return urlpatterns

def RunServer(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    url = environ['PATH_INFO']
    urlpatterns = routers()
    func = None
    for item in urlpatterns:
        if item[0] == url:
            func = item[1]
            break 
    if func:
        return func()
    else:
        return '404 not found'
    
if __name__ == '__main__':
    httpd = make_server('', 8000, RunServer)
    print "Serving HTTP on port 8000..."
    httpd.serve_forever()

二、模板引擎

在上一步驟中，對於全部的login、index均返回給用戶瀏覽器一個簡單的字符串，在現實的Web請求中通常會返回一個複雜的符合HTML規則的字符串，因此咱們通常將要返回給用戶的HTML寫在指定文件中，而後再返回。如：

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
</head>
<body>
    <h1>Index</h1>

</body>
</html>

index.html

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
</head>
<body>
    <form>
        <input type="text" />
        <input type="text" />
        <input type="submit" />
    </form>
</body>
</html>

login.html

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from wsgiref.simple_server import make_server


def index():
    # return 'index'
    f = open('index.html')
    data = f.read()
    return data


def login():
    # return 'login'
    f = open('login.html')
    data = f.read()
    return data


def routers():

    urlpatterns = (
        ('/index/', index),
        ('/login/', login),
    )

    return urlpatterns


def run_server(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    url = environ['PATH_INFO']
    urlpatterns = routers()
    func = None
    for item in urlpatterns:
        if item[0] == url:
            func = item[1]
            break
    if func:
        return func()
    else:
        return '404 not found'


if __name__ == '__main__':
    httpd = make_server('', 8000, run_server)
    print "Serving HTTP on port 8000..."
    httpd.serve_forever()

對於上述代碼，雖然能夠返回給用戶HTML的內容以現實複雜的頁面，可是仍是存在問題：如何給用戶返回動態內容？

• 自定義一套特殊的語法，進行替換
• 使用開源工具jinja2，遵循其指定語法

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title></title>
</head>
<body>
    <h1>{{name}}</h1>

    <ul>
        {% for item in user_list %}
        <li>{{item}}</li>
        {% endfor %}
    </ul>

</body>
</html>

index.html

#!/usr/bin/env python
# -*- coding:utf-8 -*-

from wsgiref.simple_server import make_server
from jinja2 import Template


def index():
    # return 'index'

    # template = Template('Hello {{ name }}!')
    # result = template.render(name='John Doe')

    f = open('index.html')
    result = f.read()
    template = Template(result)
    data = template.render(name='John Doe', user_list=['alex', 'eric'])
    return data.encode('utf-8')


def login():
    # return 'login'
    f = open('login.html')
    data = f.read()
    return data


def routers():

    urlpatterns = (
        ('/index/', index),
        ('/login/', login),
    )

    return urlpatterns


def run_server(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/html')])
    url = environ['PATH_INFO']
    urlpatterns = routers()
    func = None
    for item in urlpatterns:
        if item[0] == url:
            func = item[1]
            break
    if func:
        return func()
    else:
        return '404 not found'


if __name__ == '__main__':
    httpd = make_server('', 8000, run_server)
    print "Serving HTTP on port 8000..."
    httpd.serve_forever()

遵循jinja2的語法規則，其內部會對指定的語法進行相應的替換，從而達到動態的返回內容，對於模板引擎的本質，參考另一篇博客：http://www.cnblogs.com/wupeiqi/p/4592637.html

 

MVC和MTV設計模式

　　MVC百度百科：全名Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯彙集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不須要從新編寫業務邏輯。

　　通俗解釋：一種文件的組織和管理形式！不要被縮寫嚇到了，這其實就是把不一樣類型的文件放到不一樣的目錄下的一種方法，而後取了個高大上的名字。固然，它帶來的好處有不少，好比先後端分離，鬆耦合等等，就不詳細說明了。

模型(model)：定義數據庫相關的內容，通常放在models.py文件中。 
視圖(view)：定義HTML等靜態網頁文件相關，也就是那些html、css、js等前端的東西。 
控制器(controller)：定義業務邏輯相關，就是你的主要代碼。

　　MTV: 有些WEB框架以爲MVC的字面意思很彆扭，就給它改了一下。view再也不是HTML相關，而是主業務邏輯了，至關於控制器。html被放在Templates中，稱做模板，因而MVC就變成了MTV。這其實就是一個文字遊戲，和MVC本質上是同樣的，換了個名字和叫法而已，換湯不換藥。

　　Django的MTV模型組織

　　在web開發的項目文件中，相關目錄分開存放，必需要有機制將他們在內裏進行耦合。在Django中，urls、orm、static、settings等起着重要的做用。