Flask의 세계에 오신것을 환영합니다.¶

“마이크로(Micro)”는 무엇을 뜻하는가?¶

“마이크로”는 여러분의 웹 어플리케이션이 하나의 파이썬 파일으로 개발되야한다는 걸 말하는게 아니다.(그렇게 해석될 수 도 있겠지만…) 또한, 기능적으로 부족하다는걸 의미하지도 않는다. 마이크로 프레임워크(Microframework)에서의 “마이크로”는 핵심기능만 간결하게 유지하지만, 확장가능한 것을 목적으로 한다. Flask는 여러분을 위해 데이타베이스를 선택해주지 않는다. Flask에서 제공하는 템플릿 엔진을 변경하는것은 쉽다. 그밖에 모든것은 여러분에게 달려있고, 그래서 Flask는 여러분이 필요한 모든것일 수 있고, 필요없는것은 하나도 없을것이다.

설정과 관례¶

Flask로 시작할때, 여러분은 잘 정의된 기본값이 있는 많은 설정값들과 몇가지 관례를 볼 수 있다. 템플릿과 정적파일은 어플리케이션의 파이썬 소스 디렉토리의 하위 디렉토리에 templates과 statics에 저장된다. 이 방식은 변경할 수 있지만, 처음부터 반드시 그럴 필요는 없다.

Flask를 이용하여 성장시키기¶

여러분이 Flask를 가지고 개발할때, 운영을 위해 여러분의 프로젝트와 통합할 여러 종류의 확장을 찾게된다. Flask 핵심 개발팀은 많은 확장을 검토했고 그것들이 앞으로의 배포판과 어긋나지 않는다는것을 보증한다.

여러분의 코드의 규모가 점점 커지면서, 여러분의 프로젝트에 설계에 적합한 선택을 할 기회가 온다 Flask는 계속적으로 파이썬이 제공하는 최고의 모듈에 간결한 연결층을 제공할 것이다. 여러분은 SQLAlchemy이나 다른 디비툴 또는 알맞게 비관계형 데이타 저장소로 고급 패턴을 만들수도 있고 파이썬 웹 인터페이스인 WSGI를 위한 프레임웍에 관계없이 사용할 수 있는 툴을 이용할 수 있다.

Flask는 프레임웍의 기능을 변경하기 위한 많은 훅(hook)을 포함한다. 그것보다 더 많이 변경하고 싶다면 Flask class 자체를 상속하면 된다. 여러분이 subclassing에 관심이 있다면 크게 만들기 챕터를 확인한다. 디자인 패턴이 궁금하다면 Design Decisions in Flask 에 대한 섹션으로 넘어가라.

계속하기 설치하기, 빠르게 시작하기, 혹은 경험있는 프로그래머를 위한 머릿글.

Flask에서 쓰레드 로컬¶

Flask에 적용된 설계 원칙 중 하나는 단순한 업무는 단순해야한다는 것이다. 그런 종류의 업무들은 많은 코드를 요구하지 않아야 하지만, 여러분을 제약해서도 안된다. 그런 이유로 Flask는 놀랄만 하거나, 비전통적이라 할만한 몇개의 설계 원칙을 갖고 있다. 예를 들면, Flask는 내부적으로 쓰레드로컬 객체들(thread-local objects)을 사용한다. 그래서 쓰레드-안전한(threadsafe) 상태를 유지하기 위해 하나의 요청에서 함수들끼리 돌아가며 객체를 주고받을 필요가 없다. 이런 접근은 편리하지만, 의존 주입(dependency injection)을 하거나 요청에 고정된 값을 사용하는 코드를 재사용하려할 때 유효한 요청 문맥을 요구한다. Flask 프로젝트는 쓰레드로컬변수들(thread-locals)에 대해 투명하고, 숨기지 않고, 심지어 코드와 문서에 어디서 쓰이는지 드러내고 있다.

웹개발에서 주의점¶

웹 어플리케이션을 개발할때에는 항상 보안에 대해 신경써야한다.

여러분이 웹 어플리케이션을 만들 때, 이용자들이 개인정보를 여러분의 서버에 등록하고 저장할 수 있도록 했을 것이다. 사용자는 데이타에 있어서 여러분을 신뢰한다는 것이다. 만약 여러분이 직접 작성한 어플리케이션의 유일한 사용자라 할지라도, 자신의 데이타가 안전하기를 원할 것이다.

불행히도, 웹 어플리케이션의 보안이 타협되는 여러 가지 경우가 있다. Flask는 현대의 웹 어플리케이션의 가장 일반적인 보안 문제인 XSS로 부터 여러분을 보호한다. 굳이 여러분이 안전하지 않게 작성된 HTML을 안전하게 변환하지 않더라도, Flask와 그 하부의 Jinja2 템플릿 엔진이 여러분을 보호해준다. 그러나 보안문제를 유발하는 더 많은 경우가 있다.

이 문서는 보안에 있어 주의를 요구하는 웹 개발의 측면들을 여러분에게 경고할 것이다. 이런 보안 문제의 일부는 생각하는것 보다 훨씬 복잡하고, 우리는 취약점이 이용될 것이라는 가능성을 뛰어난 공격자가 어플리케이션의 취약점을 찾아낼 때 까지 낮게 점치곤 한다. 그리고 여러분의 어플리케이션이 공격자가 칩입할 만큼 중요하지 않다고 생각하지 마라. 공격의 종류에 따라 다르겠지만, 자동화된 bot이 여러분의 데이타베이스에 스팸이나 악성코드로의 링크 등을 채우기 위한 방법을 탐색하려 들 수 있다.

Flask도 여느 다른 프레임워크와 같이 개발시에 취약점을 주의 하여야 한다.

Python3의 상태¶

요즘 Python 공동체는 Python 프로그래밍 언어의 새로운 버전을 지원하도록 라이브러리를 개선중이다. 상황은 대단히 나아지고 있지만, 이용자들이 Python3로 넘어가는데 걸림돌이 되는 이슈들이 남아 있다. 이 문제들의 일부는 오래동안 검토되지 않은 언어의 변화에 의해 야기됐고, 부분적으로는 저수준API가 Python3의 유니코드의 바뀐점에 맞춰 어떤식으로 바뀌어야 할지를 해결해내지 못한 점에서 발생 했다.

Werkzeug과 Flask는 그 변경에 대한 해결책을 찾는 순간 Python3로 포팅되고, Python3로 개발된 버전의 업그레이드에 대한 유용한 팁을 제공할 것이다. 그때까지, 여러분은 개발하는 동안 Python2.6이나 2.7을 Python3 경고를 활성화한 상태로 사용할 것을 권고한다. 여러분이 근래에 Python3로 업그레이드를 계획중이라면 How to write forwards compatible Python code.를 읽는것을 적극 추천한다.

계속해서 설치하기 과 빠르게 시작하기 살펴볼 수 있다.

virtualenv¶

virtualenv는 아마도 당신이 개발 과정에서 꼭 사용해야만 하는 툴일것이다. 만약 당신이 운영서버에 쉘(shell) 환경에서 접속해야 하고 다양한 파이썬실행 환경이 필요하다면 유용하게 사용할 수 있는 툴이다.

virtualenv는 어떤 문제를 해결해 줄 수 있는가? 만약 당신이 나처럼 Python을 많이 사용하고 있고 Flask 기반의 웹 어플리케이션과 같이 현재 사용하고 있는 것과 다른 파이썬 환경을 사용해야 한다면 virtualenv를 사용해 볼 수 있는 좋은 기회가 될 수 있다. 게다가 당신이 진행하고 있는 더 많은 프로젝트들이 서로 다른 Python 버전에서 작동해야 한다거나 혹은 서로 다른 버전의 Python 라이브러리들 에서 작동해야 한다면 어떨까? 현실을 직시해보자! 많은 라이브러리들은 종종 하위버전 호환성들을 깨뜨린다. 그리고 어떤 심각한 응용프로그램이라 하더라도 라이브러리와 의존관계가 없을 수는 없다. 그렇다면 두개 혹은 더 많은 당신의 프로젝트들의 의존관계의 충돌을 해결하기 위해서 무엇을 할것인가?

Virtualenv가 당신을 구해 줄것이다. virtualenv를 이용하여 Python을 아무런 문제 없이 각각의 프로젝트 환경에 맞게 다중설치가 가능하도록 해준다. 이방법은 실제로 독립된 버전의 Python 실행 환경에 단순히 복사하는 것이 아니라 서로 다른 프로젝트 환경이 독립적으로 실행 환경을 명백하게 가져갈 수 있도록 격리 시키는 방법이다. 이제 virtualenv가 어떻게 작동하는지 알아보자!

만약 당신이 Mac OS X 혹은 Linux 환경이라면, 다음의 두가지 명령어로 virtualenv를 작동시킬 수 있다:

$ sudo easy_install virtualenv

혹은 좀더 나은 방법으로:

$ sudo pip install virtualenv

위의 방법을 사용하면 당신의 시스템에 virtualenv가 설치 될걸이다. 아마도 당신의 시스템에서 사용하는 package manager를 사용할 수 도 있다. 만약 당신이 우분투를 사용한다면

$ sudo apt-get install python-virtualenv

만약 당신이 Windows 를 사용하고 있거나 easy_install 명령어를 가지고 있지 않다면, 명령어를 먼저 설치해야 한다. Windows에서의 pip 와 distribute 을 확인하여 설치 방법에 대한 자세한 정보를 확인할 수 있다. easy_install이 설치가 완료되면 위와 같은 방법으로 명령어를 실행하여 virtualenv를 설치할 수 있다. 다만, Windows 환경에서는 sudo 가 필요없다.

일단 virtualenv가 설치되었다면, 쉘을 실행시키고 자신만의 실행환경을 만들 수 있다. 나는 보통 프로젝트 폴더를 만들고 폴더안에서 venv 를 이용하여 다음과 같이 작업한다.

$ mkdir myproject
$ cd myproject
$ virtualenv venv
New python executable in venv/bin/python
Installing distribute............done.

이제, 당신이 해당 프로젝트에서 작업하고 싶을 때마다, 그에 해당하는 실행환경을 활성화 시킬 수 있다. OS X혹은 Linux 환경이라면 다음과 같이 실행한다.:

$ . venv/bin/activate

만약 당신이 Windows 사용자라면, 다음과 같이 실행한다.:

$ venv\scripts\activate

어떤 방식이든, 당신은 이제 virtualenv 를 사용할 수밖에 없을 것이다. (virtualenv이 활성화된 상태를 보여주기 위핸 당신의 쉘 프롬프트가 어떻게 변화 되는지 주목하라).

이제 당신은 다음의 명령어를 입력하여 활성화된 virtualenv 를 통해 Flask를 설치할 수 있다.:

$ pip install Flask

몇초동안만 기다리면 설치가 완료 된다.

시스템 전체에 적용하여 설치¶

이 방법이 가능하긴 하지만, 추천하지는 않겠다. 단지 루트(root)권한을 이용하여 pip 를 실행시키면 된다.:

$ sudo pip install Flask

(Windows 시스템에서는 , 위 명령어를 명령어 프롬프트에서 관리자(administrator) 권한으로 실행시키면 된다. 그리고 sudo 는 생략하자.)

위태로운 모험 하기¶

만약 당신이 가장 최신버전의 Flask를 이용하여 작업을 하고 싶다면, 두가지 방법이 있다.: pip 를 이용하여 작업환경으로 Flask의 개발중 버전을 가져오거나, git checkout을 사용할 수 있다. 어떤 방법을 사용하든, virtualenv의 사용을 추천한다.

새로운 virtualenv를 만들고 git checkout을 실행하여 개발모드의 Flask를 실행할 수 있다.:

$ git clone http://github.com/mitsuhiko/flask.git
Initialized empty Git repository in ~/dev/flask/.git/
$ cd flask
$ virtualenv venv --distribute
New python executable in venv/bin/python
Installing distribute............done.
$ . venv/bin/activate
$ python setup.py develop
...
Finished processing dependencies for Flask

이 방법을 통해 의존관계에 있는 것들을 가져오게 되고 git에 등록된 현재버전을 virtualenv안으로 가져오게 된다. 그다음에 git pull origin 을 통하여 최신 버전으로 업데이트가 가능하다.

git을 사용하지 않고 최신 버전을 가져오는 방법은 다음과 같다.:

$ mkdir flask
$ cd flask
$ virtualenv venv --distribute
$ . venv/bin/activate
New python executable in venv/bin/python
Installing distribute............done.
$ pip install Flask==dev
...
Finished processing dependencies for Flask==dev

Windows에서의 pip 와 distribute¶

Windows 환경에서는 easy_install 의 설치가 조금 복잡해 보인다. 하지만 그래도 그리 어렵지 않다. 가장 쉬운 방법은 distribute_setup.py 를 다운로드 받아서 실행하는 것이다. 다운로드 폴더를 열고 다운 받은 파일을 더블클릭한다.

다음으로, easy_install 명령어를 PATH 에 실행경로로 추가하고 Python 설치 디렉토리의 Scripts의 경로도 실행경로에 추가하여야 한다. 이렇게 하려면, 바탕화면이나 시작메뉴의 내컴퓨터 아이콘을 마우스 오른쪽 버튼으로 클릭하여 나오는 메뉴에서 “등록정보”를 선택하여 실행한다. 이제 해당 메뉴에서 “고급 시스템 설정”(Windows XP의 경우 “고급” 탭) 을 선택한다. 다음으로 “환경 변수”를 선택한 후 “PATH” 를 클릭하여 “시스템 변수” 항목에 Python 설치 경로와 Python의 Scripts 폴더이름을 실행경로로 등록한다. 주의할 점은 기존에 설정되어 있는 값과 세미콜론(;)으로 구분되어져야 한다는 점이다. 설치된 Python 버전이 2.7이고 기본 경로에 설치되었다면 다음과 같을 것이다.:

;C:\Python27\Scripts

마침내 당신은 해냈다! 이제 제대로 동작하는지 확인해 보자, 명령어 창을 열고 프롬프트에 easy_install. 만약 Windows Vista 혹은 Windows7 을 사용중이고 ‘User Account Control’ 이 활성화 되어 있다면 관리자 권한으로 진행하여야 한다.

이제 당신은 easy_install 를 손에 넣었다! pip 를 설치해 보자:

> easy_install pip

기본 애플리케이션¶

기본 Flask 어플리케이션은 다음과 같은 모습이다.

from flask import Flask
app = Flask(__name__)

@app.route('/')
def hello_world():
    return 'Hello World!'

if __name__ == '__main__':
    app.run()

이 내용을 hello.py (아니면 비슷한 다른 이름으로) 저장하고 파이썬 인터프리터로 실행한다. 여러분이 작성한 어플리케이션을 `flask.py`로 호출하지 않도록 주의해라. 왜냐하면 Flask 자체와 충돌이 나기 때문이다.

$ python hello.py
 * Running on http://127.0.0.1:5000/

자, 이제 웹브라우져를 열고 http://127.0.0.1:5000/, 로 이동해보자 그러면, 여러분이 작성한 hello world greeting이 화면에 나와야한다.

그렇다면, 위의 코드는 무슨 일은 한걸까?

1. 먼저 우리는 Flask class를 임포트했다. 이 클래스의 인스턴스가 우리의 WSGI어플리케이션이 될것이다. 첫번째 인자는 이 어플리케이션의 이름이다. 여러분이 단일 모듈을 사용한다면(위의 예제처럼),여러분은 __name__`을 사용해야한다. 왜냐하면, 어플리케이션으로 시작되는지, 혹은 모듈로 임포트되는지에 따라 이름이 달라지기 때문이다.(`‘__main__’`` 대 실제로 임포트한 이름) 더 자세한 정보는 Flask 문서를 참고해라.
2. 다음은 Flask class의 인스턴스를 생성한다. 인자로 모듈이나 패키지의 이름을 넣는다. 이것은 플라스크에서 팀플릿이나 정적파일을 찾을때 필요하다.
3. route() 데코레이터를 사용해서 Flask에게 어떤 URL이 우리가 작성한 함수를 실행시키는지 알려준다.
4. 작성된 함수의 이름은 그 함수에 대한 URL을 생성하는데 사용되고(url_for 함수 참고), 그 함수는 사용자 브라우저에 보여줄 메시지를 리턴한다.
5. 최종적으로 run() 함수를 사용해서 우리가 개발한 어플리케이션을 로컬서버로 실행한다. 소스파일을 모듈이 아닌 python 인터프리터를 이용해서 직접 실행한다면 if __name__ == '__main__': 이 문장은 우리가 실행한 서버가 현재 동작되는 유일한 서버라는 것을 보장한다.

실행된 서버를 중지하려면, control-C를 누른다. .. _public-server:

app.run(host='0.0.0.0')

디버그 모드¶

run() 메소드는 로컬개발서버를 실행시키기에 좋지만 코드 변경후에 수동으로 재시작해야한다. 플라스크는 그런 번거로운것을 개선한 방식을 제공한다. 여러분이 디버그모드를 지원하면, 서버는 코드변경을 감지하고 자동으로 리로드하고, 문제가 발생하면 문제를 찾을수 있도록 디버거를 제공한다.

디버깅을 활성화하는 두가지 방식이 있다. 한가지는 어플리케이션 객체에 플래그로 설정하는 방식이거나

app.debug = True
app.run()

어플리케이션을 실행할때 파라미터로 넘겨주는 방식이다.

app.run(debug=True)

두 메소드는 같은 결과를 보여준다.

디버거의 스크린샷:

디버거에 대해 좀 더 궁금하다면 디버거로 작업하기 를 참고 하기 바란다.

라우팅¶

현대 웹 어플리케이션은 잘 구조화된 URL로 구성되있다. 이것으로 사람들은 URL을 쉽게 기억할 수 있고, 열악한 네트워크 연결 상황하의 기기들에서 동작하는 어플리케이션에서도 사용하기 좋다. 사용자가 인덱스 페이지를 거치지 않고 바로 원하는 페이지로 접근할 수 있다면, 사용자는 그 페이지를 좋아할 것이고 다시 방문할 가능성이 커진다.

위에서 본것처럼, route() 데코레이터는 함수와 URL을 연결해준다. 아래는 기본적인 예제들이다.

@app.route(‘/’) def index():

return ‘Index Page’

@app.route(‘/hello’) def hello():

return ‘Hello World’

하지만, 여기엔 더 많은것이 있다. 여러분은 URL을 동적으로 구성할 수 있고, 함수에 여러 룰을 덧붙일수있다.

@app.route('/user/<username>')
def show_user_profile(username):
    # show the user profile for that user
    return 'User %s' % username

@app.route('/post/<int:post_id>')
def show_post(post_id):
    # show the post with the given id, the id is an integer
    return 'Post %d' % post_id

@app.route('/projects/')
def projects():
    return 'The project page'

@app.route('/about')
def about():
    return 'The about page'

>>> from flask import Flask, url_for
>>> app = Flask(__name__)
>>> @app.route('/')
... def index(): pass
...
>>> @app.route('/login')
... def login(): pass
...
>>> @app.route('/user/<username>')
... def profile(username): pass
...
>>> with app.test_request_context():
...  print url_for('index')
...  print url_for('login')
...  print url_for('login', next='/')
...  print url_for('profile', username='John Doe')
...
/
/login
/login?next=/
/user/John%20Doe

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        do_the_login()
    else:
        show_the_login_form()

정적 파일¶

동적인 웹 어플리케이션은 정적 파일은 필요로한다. 그것들은 보통 자바스크립트나 CSS파일을 의미한다. 이상적으로 웹서버는 정적 파일들을 서비스하지만, 개발시에는 플라스크가 그 역할을 대신해준다. 단지 static 이라는 폴더를 여러분이 생성한 패키지 아래에 만들거나 모듈 옆에 위치시키면 개발된 어플리케이션에서 /static 위치에서 정적 파일을 제공할 것이다.

정적파일에 대한 URL을 얻으려면, 특별한 'static' 끝점 이름을 사용해야한다

url_for('static', filename='style.css')

이 파일(style.css)는 파일시스템에 static/style.css 로 저장되어야한다.

템플릿 보여주기¶

파이썬 소스코드에서 HTML을 생성하는 것은 그다지 재밌는 일은 아니다.(굉장히 번거로운 일이다) 왜냐하면 어플리케이션 보안을 위해 동적으로 변환되는 값에 대해 이스케이핑을 여러분 스스로 작성해야한다. 그런 불편함때문에 Flask는 <http://jinja.pocoo.org/2/>`_ 를 템플릿엔진으로 구성하여 자동으로 HTML 이스케이핑을 한다.

템플릿을 뿌려주기 위해, 어려분은 render_template() 메소드를 사용할 수 있다. 여러분이 해야하는 것은 단지 템플릿의 이름과 템플릿에 보여줄 변수를 키워드 인자로 넘겨주면 된다. 아래는 템플릿을 뿌려주는 방식의 간단한 예를 보여준다

from flask import render_template

@app.route('/hello/')
@app.route('/hello/<name>')
def hello(name=None):
    return render_template('hello.html', name=name)

Flask는 templates 폴더에서 템플릿을 찾는다. 여러분이 모듈로 어플리케이션을 개발했다면 이 폴더는 그 모듈 옆에 위치하고, 패키지로 개발했다면 그 패키지 안에 위치한다 :

Case 1: 모듈:

/application.py
/templates
    /hello.html

Case 2: 패키지:

/application
    /__init__.py
    /templates
        /hello.html

플라스크에서는 템플릿에 있어서 Jinja2의 강력함을 사용할 수 있다. Jinja2에 대한 더 자세한 내용은 Jinja2 Template Documentation 공식 문서를 참고하기 바란다.

여기 템플릿 예제가있다:

<!doctype html>
<title>Hello from Flask</title>
{% if name %}
  <h1>Hello {{ name }}!</h1>
{% else %}
  <h1>Hello World!</h1>
{% endif %}

템플릿 안에서도 여러분은 request,:class:~flask.session 와 g [1] 객체에 접근할 수 있다.

템플릿에서 특히 상속이 유용하게 사용된다. 템플릿 상속에 대해서 자세한 내용을 보고 싶으면 템플릿 상속 패턴문서를 참고하기 바란다. 기본적으로 템플릿 상속은 각 페이지에서 특정 요소를 유지할수 있게 해준다.(헤더, 네비게이션과 풋터)

자동 이스케이핑은 켜져있고, name 이란 변수가 HTML에 포함되있다면, 그 변수값은 자동으로 이스케이핑된다. 여러분이 변수가 안전하고 그 변수를 안전한 HTML로 만든다면, Markup 템플릿에서 |safe 필터를 사용해서 안전하게 만들수 있다. 템플릿에 대한 자세한 내용은 Jinja2 문서를 참고하기 바란다.

여기에 Markup 클래스를 사용하는 예제가 있다:

>>> from flask import Markup
>>> Markup('<strong>Hello %s!</strong>') % '<blink>hacker</blink>'
Markup(u'<strong>Hello &lt;blink&gt;hacker&lt;/blink&gt;!</strong>')
>>> Markup.escape('<blink>hacker</blink>')
Markup(u'&lt;blink&gt;hacker&lt;/blink&gt;')
>>> Markup('<em>Marked up</em> &raquo; HTML').striptags()
u'Marked up \xbb HTML'

요청 데이타 접근하기¶

웹 어플리케이션에 있어서 클라이언트에서 서버로 보내는 데이타를 처리하는 것은 중요한 일이다. Flask에서 이 정보는 글로벌한 request 객체에 의해 제공된다. 여러분이 파이썬 경험이 있다면, 어떻게 그 객체가 글로벌하고 쓰레드 안전하게 처리되는지 궁금할 수 도 있다. 그 답은 컨텍스트 로컬에 있다. :

from flask import request

with app.test_request_context('/hello', method='POST'):
    # now you can do something with the request until the
    # end of the with block, such as basic assertions:
    assert request.path == '/hello'
    assert request.method == 'POST'

from flask import request

with app.request_context(environ):
    assert request.method == 'POST'

from flask import request

@app.route('/login', methods=['POST', 'GET'])
def login():
    error = None
    if request.method == 'POST':
        if valid_login(request.form['username'],
                       request.form['password']):
            return log_the_user_in(request.form['username'])
        else:
            error = 'Invalid username/password'
    # 아래의 코드는 요청이 GET 이거나, 인증정보가 잘못됐을때 실행된다.
    return render_template('login.html', error=error)

searchword = request.args.get('key', '')

from flask import request

@app.route('/upload', methods=['GET', 'POST'])
def upload_file():
    if request.method == 'POST':
        f = request.files['the_file']
        f.save('/var/www/uploads/uploaded_file.txt')
    ...

from flask import request
from werkzeug import secure_filename

@app.route('/upload', methods=['GET', 'POST'])
def upload_file():
    if request.method == 'POST':
        f = request.files['the_file']
        f.save('/var/www/uploads/' + secure_filename(f.filename))
    ...

from flask import request

@app.route('/')
def index():
    username = request.cookies.get('username')
    # use cookies.get(key) instead of cookies[key] to not get a
    # KeyError if the cookie is missing.

from flask import make_response

@app.route('/')
def index():
    resp = make_response(render_template(...))
    resp.set_cookie('username', 'the username')
    return resp

리다이렉션과 에러¶

사용자가 다른 엔드포인트로 redirect하기 위해서는 redirect() 함수를 사용하라. 에러콛를 가지고 일찍 요청을 중단하기를 원한다면 abort() 함수를 사용하라:

from flask import abort, redirect, url_for

@app.route('/')
def index():
    return redirect(url_for('login'))

@app.route('/login')
def login():
    abort(401)
    this_is_never_executed()

위 코드는 사용자가 인덱스 페이지에서 그들이 접근할 수 없는(401은 접근불가를 의미) 페이지로 redirect되어질 것이기 때문에 다소 무의미한 예제일 수는 있으나 어떻게 작동된다는 것을 보여주고 있다.

기본으로 하얀 화면에 검정 글씨의 에러 페이지가 각 에러코드를 위해 보여진다. 만약 여러분이 에러페이지를 변경하기를 원한다면 errorhandler() 데코레이터를 사용할 수 있다:

from flask import render_template

@app.errorhandler(404)
def page_not_found(error):
    return render_template('page_not_found.html'), 404

render_template() 호출 뒤에 있는 404 를 주목해하. 이것은 페이지의 상태 코드가 그 페이지를 찾을 수 없다는 404가 되어야 하는 것을 Flask에게 말해 준다. 기본으로 200이 가정되며, 그것은 모든 것이 잘 실행됐다는 것으로 해석된다.

응답에 관하여¶

view 함수로부터 반환되는 값은 자동으로 response 객체로 변환된다. 만약 반환값이 문자열이라면 response body로 문자열과 200 OK 코드, text/html mimtype을 갖는 response객체로 변환된다. Flask에서 반환값을 response 객체로 변환하는 로직은 아래와 같다:

1. 만약 정확한 유형의 response객체가 반환된다면 그 객체는 그대로 뷰로부터 반환되어 진다.
2. 만약 문자열이 반환된다면, response객체는 해당 데이타와 기본 파라미터들을 갖는 reponse객체가 생성된다.
3. 만약 튜플이 반환된다면 튜플 안에 있는 아이템들이 추가적인 정보를 제공할 수 있다. 그런 퓨틀들은 지정된 폼 (response, status, headers) 이여야 하며, 그 중 적어도 하나의 아이템이 튜플 안에 있어야 한다. status 값은 statud code를 오버라이드하면 ` headers` 는 추가적인 정보의 list, dictionary가 될 수 있다.
4. 만약 위의 것들이 아무것도 적용되지 않는다면, Flask는 반환값이 유효한 WSGI application 이라고 가정하고 WSGI application을 response객체로 변환할 것이다.

만약 여러분이 뷰 안에서 결과 response 객체를 찾기를 원한다면 make_response() 함수를 사용할 수 있다.

아래와 같은 뷰를 가지고 있다고 상상해 보아라:

@app.errorhandler(404)
def not_found(error):
    return render_template('error.html'), 404

여러분은 단지 make_response() 함수를 사용하여 반환되는 표현을 래핑하고, 변경을 위해 결과 객체를 얻은 다음 반환하기만 하면 된다:

@app.errorhandler(404)
def not_found(error):
    resp = make_response(render_template('error.html'), 404)
    resp.headers['X-Something'] = 'A value'
    return resp

세션¶

Request object외에도 하나의 요청에서 다음 요청까지 사용자에 대한 구체적인 정보를 저장할 수 있는 session 이라는 객체가 있다. 세션은 여러분을 위해 쿠키 위에서 구현되어 지고 암호화를 사용하여 그 쿠키를 서명한다. 즉, 사용자는 쿠키의 내용을 볼 수는 있지만 서명을 위해 사용된 비밀키를 알지 못한다면 쿠키의 내용을 변경할 수 없다는 것을 의미한다.

세션을 사용하기 위해서는 비밀키를 설정해야 한다. 아래 세션이 어떻게 사용되는지 참조해라:

from flask import Flask, session, redirect, url_for, escape, request

app = Flask(__name__)

@app.route('/')
def index():
    if 'username' in session:
        return 'Logged in as %s' % escape(session['username'])
    return 'You are not logged in'

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        session['username'] = request.form['username']
        return redirect(url_for('index'))
    return '''
        <form action="" method="post">
            <p><input type=text name=username>
            <p><input type=submit value=Login>
        </form>
    '''

@app.route('/logout')
def logout():
    # remove the username from the session if it's there
    session.pop('username', None)
    return redirect(url_for('index'))

# set the secret key.  keep this really secret:
app.secret_key = 'A0Zr98j/3yX R~XHH!jmN]LWX/,?RT'

위 예제에서 escape() 는 템플릿 엔진을 사용하지 않을경우 이스케이프를 한다.

무작위(랜덤)로 생성하는 것의 문제는 정말 그것이 무작위(랜덤)한 것인지 판단하기 어렵다는 것이다. 비밀키는 가능한 한 무작위로 생성되어야 하다. 여러분의 OS는 키를 얻는 데 사용할 수 있는 cryptographic random generator(암호 난수 발생기) 기반의 꽤 무작위의 키를 생성하는 방법을 제공한다. :

>>> import os
>>> os.urandom(24)
'\xfd{H\xe5<\x95\xf9\xe3\x96.5\xd1\x01O<!\xd5\xa2\xa0\x9fR"\xa1\xa8'

위 코드를 여러분의 코드에 복사하기/붙혀넣기만 하면 된다.

쿠키 기반의 세션: Flask는 여러분이 값들을 세션 객체 안에 넣고 세션 객체들을 쿠키로 직렬화할 것이다. 만약 쿠키는 사용 가능하나 세션에 저장한 값들이 여러 요청에 걸쳐 지속적으로 사용할 수 없다는 것을 발견한다면, 그리고 분명한 에러 메세지를 얻지 못한다면, 웹 브라우저에 의해 지원되는 쿠키 크기와 응답 페이지 내의 쿠키 크기를 확인해라.

메시지 플래싱¶

좋은 어플리케이션과 유저 인터페이스는 모두 피드백에 관한 것이다. 만약 사용자가 충분한 피드백을 받지 못한다면 사용자들은 아마 결국에는 그 어플리케이션을 싫어할 것이다. Flask는 flashing system을 사용하여 사용자에게 피드백을 주기 위한 정말 간단한 방법을 제공한다. flashing system이란 기본적으로 요청의 끝과 바로 다음 요청에 접근할 때 메세지를 기록하는 것을 가능하게 한다. 이것은 보통 메세지를 사용자에게 노출하기 위한 레이아웃 템플릿과 조합되어 있다.

메세지를 flash 하기 위하여 flash() 메소드를 사용하고 메세지를 가져오기 위하여 템플릿에서 사용할 수 있는 get_flashed_messages() 메소드를 사용할 수 있다. 예제가 필요하면 메시지 플래싱(Message Flashing) 챕터를 확인하기 바란다.

로깅¶

때때로 여러분은 정확해야 하는 데이타를 다뤄야 하나 실제로는 그렇지 못한 상황에 처할 지도 모른다. 예를 들면 형식이 틀린 HTTP 요청을 서버로 보내는 클라이언트 사이드 코드를 가질 지도 모른다. 이런 상황은 사용자가 데이타 조작에 의해 발생할 수 있으며, 클라이언트 코드는 정상적으로 실행되지 않을 것이다. 대부분의 경우에는 이런 상황에서 400 Bad Request 로 응답하는 것은 상관없으나 때때로 400 Bad Request 로 응답하지 않고 코드가 정상적으로 실행되어야 하는 경우가 있다.

이런 경우 여러분은 여전히 수상한 어떤 일이 발생한 것을 로깅하기를 원할지도 모른다. 이런 상황에서 로걸ㄹ 사용할 수 있다. Flask 0.3부터 로거는 여러분이 사용할 수 있도록 미리 설정되어 있다.

아래 로그를 출력하는 예제가 있다.

app.logger.debug('A value for debugging')
app.logger.warning('A warning occurred (%d apples)', 42)
app.logger.error('An error occurred')

첨부된 Logger 이다. 더 많은 정보를 원하면 logging documentation 문서를 참조해라.

WSGI 미들웨어에서 후킹하기¶

만약 여러분이 여러분이 개발한 어플리케이션을 WSGI 미들웨어에 올리기를 원한다면 여러분은 내부 WSGI 어플리케이션을 래핑할 수 있다. 예를 들면 여러분이 lighttpd의 버그를 피하기 위해 Werkzeug 패키지의 미들웨어 중 하나를 사용하기를 원한다면, 여러분은 아래 코드와 같이 내부 WSGI 어플리케이션을 래핑할 수 있다:

from werkzeug.contrib.fixers import LighttpdCGIRootFix
app.wsgi_app = LighttpdCGIRootFix(app.wsgi_app)

웹서버에 배포하기¶

여러분이 Flask로 개발한 어플리케이션을 배포할 준비가 되었는가? quickstart를 마무리하기 위하여 여러분은 hosted된 플랫폼에 배포할 수 있다. 모든 플랫폼들은 소규모 프로젝트를 위해 무료 서비스를 제공한다:

• Deploying Flask on Heroku
• Deploying WSGI on dotCloud with Flask-specific notes

Flask 어플리케이션을 host할 수 있는 다른 곳도 있다:

• Deploying Flask on Webfaction
• Deploying Flask on Google App Engine
• Sharing your Localhost Server with Localtunnel

만약 여러분이 자신만의 host를 관리하고 서비스하기를 원한다면, 배포 옵션 챕터를 참조하라.

Jinja 설정¶

사용자가 임의로 설정하지 않는이상, Jinja2는 다음과 같이 Flask에 의해 설정되어 있다.:

• 자동변환(autoescaping) 기능은 .html , .xml 과 .xhtml 과 같은 모든 템플릿 파일들에 대해서 기본으로 활성화되어 있다.
• 하나의 템플릿은 in/out에 대한 자동변환(autoescape) 기능을 {% autoescape %} 태그를 이용하여 사용할 수 있다.
• Flask는 기본적으로 Jinja2 컨텍스트(context)를 통해서 전역 함수들과 헬퍼함수들을 제공한다.

표준 컨텍스트¶

다음의 전역 변수들은 Jinja2에서 기본으로 사용가능하다.:

config

현재 설정값을 가지고 있는 객체 (flask.config)

버전 0.6에 추가.

버전 0.10으로 변경: This is now always available, even in imported templates.

request

현재 요청된 객체 (request object) (flask.request). 이 변수는 템플릿이 활성화된 컨텍스트에서 요청된것이 아니라면 유효하지 않다.

session

현재 가지고 있는 세션 객체 (flask.session). 이 변수는 템플릿이 활성화된 컨텍스트에서 요청된것이 아니라면 유효하지 않다.

g

요청(request)에 한정되어진 전역 변수 (flask.g) . 이 변수는 템플릿이 활성화된 컨텍스트에서 요청된것이 아니라면 유효하지 않다.

url_for()

flask.url_for() 함수 참고.

get_flashed_messages()

flask.get_flashed_messages() 함수 참고.

{% from '_helpers.html' import my_macro with context %}

표준 필터¶

다음 필터들은 Jinja2에서 자체적으로 추가 제공되어 이용할 수 있는 것들이다.:

tojson()

이 기능은 JSON 표기법으로 주어진 객체를 변환기켜주는 것이다. 예를들어 만약 JavaScript를 즉석에서 생성하려고 한다면 이기능은 많은 도움이 될것이다.

script 태그안에서는 변환(escaping)이 반드시 일어나서는 안되기 때문에, |safe 필터가 script 태그안에서 비활성화되도록 보장해야 한다.:

<script type=text/javascript>
    doSomethingWith({{ user.username|tojson|safe }});
</script>

|tojson 필터는 올바르게 슬래쉬들을 변환해 준다.

자동변환(Autoescaping) 제어하기¶

자동변환(Autoescaping)은 자동으로 특수 문자들을 변환시켜주는 개념이다. 특수문자들은 HTML (혹은 XML, 그리고 XHTML) 문서 에서 &, >, <, " , ' 에 해당한다. 이 문자들은 해당 문서에서 특별한 의미들을 담고 있고 이 문자들을 텍스트 그대로 사용하고 싶다면 “entities” 라고 불리우는 값들로 변환하여야 한다. 이렇게 하지 않으면 본문에 해당 문자들을 사용할 수 없어 사용자에게 불만을 초래할뿐만 아니라 보안 문제도 발생할 수 있다. (다음을 참고 Cross-Site Scripting (XSS))

그러나 때때로 템플릿에서 이러한 자동변환을 비활성화 할 필요가 있다. 만약 명시적으로 HTML을 페이지에 삽입하려고 한다면, 예를 들어 HTML로 전환되는 마크다운(markdown)과 같은 안전한 HTML을 생성하는 특정 시스템으로부터 오는 것일 경우에는 유용하다.

이 경우 세가지 방법이 있다:

• Python 코드에서는, HTML 문자열을 Markup 객체를 통해서 템플릿에 전달되기 전에 래핑한다. 이방법은 일반적으로 권장되는 방법이다.
• 템플릿 내부에, |safe 필터를 명시적으로 사용하여 문자열을 안전한 HTML이 되도록 한다. ({{ myvariable|safe }})
• 일시적으로 모두 자동변환(autoescape) 시스템을 해제한다.

템플릿에서 자동변환(autoescape) 시스템을 비활성화 하려면, {%autoescape %} 블럭을 이용할 수 있다. :

{% autoescape false %}
    <p>autoescaping is disabled here
    <p>{{ will_not_be_escaped }}
{% endautoescape %}

이 블럭이 수행될때마다, 이 블록에서 사용하는 변수애 대해 각별한 주의를 기울여야 한다.

필터 등록하기¶

만약 Jinja2에서 자신만의 필터를 직접 등록하기를 원한다면 두가지 방법이있다. 다음의 방법을 이용할 수 있다. jinja_env Jinja 어플리케이션에서 이용하거나 template_filter() 데코레이터(decorator)를 이용가능하다.

다음 두개의 예제는 객체의 값을 거꾸로 만드는 같은 일을 한다:

@app.template_filter('reverse')
def reverse_filter(s):
    return s[::-1]

def reverse_filter(s):
    return s[::-1]
app.jinja_env.filters['reverse'] = reverse_filter

만약 함수이름을 필터이름으로 사용하려면 데코레이터(decorator)의 아규먼트는 선택조건이어야한다. 한번 필터가 등록되면, Jinja2의 내장 필터를 사용하는 것과 똑같이 사용이 가능하다, 예를 들면 만약 mylist 라는 Python 리스트(list)가 컨텍스트에 있다면

{% for x in mylist | reverse %}
{% endfor %}

컨텍스트 프로세서(context processor)¶

새로운 변수들을 자동으로 템플릿의 컨텍스트에 주입시키기 위해서 Flask에는 컨텍스트 프로세서들이 존재한다. 컨텍스트 프로세서들은 새로운 값들을 템플릿 컨텍스트에 주입시키기 위해 템플릿이 렌더링되기 전에 실행되어야 한다. 템플릿 프로세서는 딕셔너리(dictionary) 객체를 리턴하는 함수이다. 이 딕셔너리의 키와 밸류들은 어플리케이션에서의 모든 템플릿들을 위해서 템플릿 컨텍스트에 통합된다.:

@app.context_processor
def inject_user():
    return dict(user=g.user)

위의 컨텍스트 프로세서는 user 라고 부르는 유효한 변수를 템플릿 내부에 g.user 의 값으로 만든다. 이 예제는 g 변수가 템플릿에서 유효하기 때문에 그렇게 흥미롭지는 않지만 어떻게 동작하는지에 대한 아이디어를 제공한다.

변수들은 값들에 제한되지 않으며, 또한 컨텍스트 프로세서는 템플릿에서 함수들을 사용할 수 있도록 해준다. (Python이 패싱 어라운드(passing around)함수를 지원하기 때문에):

@app.context_processor
def utility_processor():
    def format_price(amount, currency=u'€'):
        return u'{0:.2f}{1}'.format(amount, currency)
    return dict(format_price=format_price)

위의 컨텍스트 프로세서는 format_price 함수를 모든 템플릿들에서 사용가능하도록 해준다

{{ format_price(0.33) }}

또한 format_price 를 템플릿 필터로 만들 수도 있다. (다음을 참고 필터 등록하기), 하지만 이 예제에서는 컨텍스트 프로세서에 어떻게 함수들을 전달하는지에 대해서만 설명한다.

어플리케이션¶

첫째로 우리는 테스트할 어플리케이션이 필요하다. 우리는 튜토리얼 에서 소개된 어플리케이션을 사용할 것이다. 아직 어플리케이션이 준비되지 않았다면 the examples 에서 소스코드를 준비하자.

테스팅 스켈레톤(Skeleton)¶

어플리케이션을 테스트 하기 위해서, 우리는 두번째 모듈 (flaskr_tests.py) 을 추가하고 단위테스트 스켈레톤(Skeleton)을 만든다.:

import os
import flaskr
import unittest
import tempfile

class FlaskrTestCase(unittest.TestCase):

    def setUp(self):
        self.db_fd, flaskr.app.config['DATABASE'] = tempfile.mkstemp()
        flaskr.app.config['TESTING'] = True
        self.app = flaskr.app.test_client()
        flaskr.init_db()

    def tearDown(self):
        os.close(self.db_fd)
        os.unlink(flaskr.app.config['DATABASE'])

if __name__ == '__main__':
    unittest.main()

setUp() 함수의 코드는 새로운 테스트 클라이어트를 생성하고 새로운 데이터베이스를 초기화 한다. 이 함수는 각각의 테스트 함수가 실행되기 전에 먼저 호출된다. 테스트후 데이터베이스를 삭제하기 위해 tearDown() 함수에서 파일을 닫고 파일시스템에서 제거 할 수 있다. 또한 setup 함수가 실행되는 동안에 TESTING 플래그(flag)가 활성화된다. 요청을 처리하는 동안에 오류 잡기(error catch)가 비활성화되어 있는 것은 어플리케이션에대한 성능테스트에 대하여 좀 더 나은 오류 리포트를 얻기 위해서이다.

이 테스트 클라이언트는 어플리케이션에대한 단순한 인터페이스를 제공한다. 우리는 어플리케이션에게 테스트 요청을 실행시킬 수 있고, 테스트 클라이언트는 이를 위해 쿠키를 놓치지 않고 기록한다.

SQLite3는 파일시스템 기반이기 때문에 임시 데이터베이스를 생성할때 tempfile 모듈을 사용하여 초기화 할 수 있다. mkstemp() 함수는 두가지 작업을 수행한다: 이 함수는 로우-레벨 파일핸들과 임의의 파일이름을 리턴한다. 여기서 임의의 파일이름을 데이터베이스 이름으로 사용한다. 우리는 단지 db_fd 라는 파일핸들을 os.close() 함수를 사용하여 파일을 닫기전까지 유지하면 된다.

만약 지금 테스트 실행한다면, 다음과 같은 출력내용을 볼 수 있을 것이다.:

$ python flaskr_tests.py

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

비록 실제 테스트를 실행하지는 않았지만, 우리는 이미 flaskr 어플리케이션의 문법구문상으로 유효하다는 것을 벌써 알게되었다, 그렇지 않다면 어플리케이션이 종료되는 예외상황을 겪었을 것이다.

첫번째 테스트¶

이제 어플리케이션의의 기능 테스트를 시작할 시간이다. 어플리케이션의 루트 (/)로 접근하였을때 어플리케이션이 “No entries here so far” 를 보여주는지 확인해야 한다. 이 작업을 수행하기 위해서, 우리는 새로운 테스트 메소드를 다음과 같이 클래스에 추가하여야 한다.:

class FlaskrTestCase(unittest.TestCase):

    def setUp(self):
        self.db_fd, flaskr.app.config['DATABASE'] = tempfile.mkstemp()
        self.app = flaskr.app.test_client()
        flaskr.init_db()

    def tearDown(self):
        os.close(self.db_fd)
        os.unlink(flaskr.DATABASE)

    def test_empty_db(self):
        rv = self.app.get('/')
        assert 'No entries here so far' in rv.data

우리의 테스트 함수들의 이름이 test 로 시작하고 있다는 것에 주목하자. 이점을 활용하여 unittest 에서 테스트를 수행할 함수를 자동적으로 식별할 수 있다.

self.app.get 를 사용함으로써 HTTP GET 요청을 주어진 경로에 보낼 수 있다. 리턴값은 response_class 객체의 값이 될 것이다. 이제 data 의 속성을 사용하여 어플리케이션 으로부터 넘어온 리턴 값(문자열)을 검사 할 수 있다. 이런 경우, 'No entries here so far' 가 출력 메시지에 포함되어 있는 것을 확인해야 한다.

다시 실행해 보면 하나의 테스트에 통과 한 것을 확인할 수 있을 수 있을 것이다.

$ python flaskr_tests.py
.
----------------------------------------------------------------------
Ran 1 test in 0.034s

OK

입력과 출력 로깅¶

우리의 어플리케이션에서 대부분의 기능은 관리자만 사용이 가능하다. 그래서 우리의 테스트 클라이언트에서는 어플리케이션의 입력과 출력에대한 로그를 기록할 수 있어야 한다. 이 작업을 작동시키려면, 로그인과 로그아웃 페이지요청들에 폼 데이터(사용자이름과 암호) 를 적용해야 한다. 그리고 로그인과 로그아웃 페이지들은 리다이렉트(Redirect)되기 때문에 클라이언트에게 follow_redirects 를 설정해 주어야 한다.

다음의 두 함수를 FlaskrTestCase 클래스에 추가 하자

def login(self, username, password):
    return self.app.post('/login', data=dict(
        username=username,
        password=password
    ), follow_redirects=True)

def logout(self):
    return self.app.get('/logout', follow_redirects=True)

이제 로그인과 로그아웃에 대해서 잘 작동하는지, 유효하지 않은 자격증명에 대해서 실패 하는지 쉽게 테스트 하고 로깅 할 수 있다. 다음의 새로운 테스트를 클래스에 추가 하자:

def test_login_logout(self):
    rv = self.login('admin', 'default')
    assert 'You were logged in' in rv.data
    rv = self.logout()
    assert 'You were logged out' in rv.data
    rv = self.login('adminx', 'default')
    assert 'Invalid username' in rv.data
    rv = self.login('admin', 'defaultx')
    assert 'Invalid password' in rv.data

메시지 추가 테스트¶

메시지를 추가 하게 되면 잘 작동하는지 확인해야만 한다. 새로운 테스트 함수를 다음과 같이 추가 하자

def test_messages(self):
    self.login('admin', 'default')
    rv = self.app.post('/add', data=dict(
        title='<Hello>',
        text='<strong>HTML</strong> allowed here'
    ), follow_redirects=True)
    assert 'No entries here so far' not in rv.data
    assert '&lt;Hello&gt;' in rv.data
    assert '<strong>HTML</strong> allowed here' in rv.data

여기에서 우리가 의도한 대로 제목을 제외한 부분에서 HTML이 사용가능한지 확인한다.

이제 실행 하면 세가지 테스트를 통과 할 것이다.:

$ python flaskr_tests.py
...
----------------------------------------------------------------------
Ran 3 tests in 0.332s

OK

헤더값들과 상태코드들이 포함된 보다 복잡한 테스트를 위해서는, MiniTwit Example 예제 소스의 좀 더 큰 어플리케이션의 테스트 수헹방법을 확인하자.

다른 테스팅 기법들¶

위에서 살펴본 대로 테스트 클라이언트를 사용하는 것 이외에, test_request_context() 함수를 with 구문과 조합하여 요청 컨텍스트를 임시적으로 할성화 하기 위해 사용 될 수 있다. 이것을 이용하여 request , g 과 session 같은 뷰 함수들에서 사용하는 객체들에 접근 할 수 있다. 다음 예제는 이런 방법들을 보여주는 전체 예제이다.:

app = flask.Flask(__name__)

with app.test_request_context('/?name=Peter'):
    assert flask.request.path == '/'
    assert flask.request.args['name'] == 'Peter'

컨텍스트와 함께 바인드된 모든 객체는 같은 방법으로 사용이 가능하다.

만약 서로 다른 설정구성으로 어플리케이션을 테스트하기 원할경우 이것을 해결하기 위한 좋은 방법은 없는것 같다. 이와 같이 어플리케이션을 테스트 하려면 어플리케이션 팩토리에 대해서 고혀해 보길 바란다. (참고 어플리케이션 팩토리)

그러나 만약 테스트 요청 컨텍스트를 사용하는 경우 before_request() 함수 와 after_request() 는 자동으로 호출되지 않는다. 반면에:meth:~flask.Flask.teardown_request 함수는 with 블럭에서 요청 컨텍스트를 빠져나올때 실제로 실행된다. 만약 before_request() 함수도 마찬가지로 호출되기를 원한다면, preprocess_request() 를 직접 호출해야 한다.:

app = flask.Flask(__name__)

with app.test_request_context('/?name=Peter'):
    app.preprocess_request()
    ...

이경우 어플리케이션이 어떻게 설계되었느냐에 따라 데이터베이스 컨넥션 연결이 필요할 수도 있다.

만약 after_request() 함수를 호출하려 한다면, process_response() 함수에 응답객체(Response Object)를 전달하여 직접 호출하여야 한다:

app = flask.Flask(__name__)

with app.test_request_context('/?name=Peter'):
    resp = Response('...')
    resp = app.process_response(resp)
    ...

이같은 방식은 일반적으로 해당 시점에 직접 테스트 클라이언트를 사용 할 수 있기 때문에 크게 유용한 방법은 아니다.

컨텍스트 유지시키기¶

때로는 일반적인 요청이 실행되는 경우에도 테스트 검증이 필요해질 경우가 있기 때문에 컨텍스트 정보를 좀더 유지 하는 것이 도움이 될 수 있다. Flask 0.4 버전에서 부터는 test_client() 를 with 블럭과 함께 사용하면 가능하다.:

app = flask.Flask(__name__)

with app.test_client() as c:
    rv = c.get('/?tequila=42')
    assert request.args['tequila'] == '42'

만약 test_client() 를 with 블럭이 없이 사용한다면 , request 가 더이상 유효하지 않기 때문에 assert 가 실패 하게 된다. (그 이유는 실제 요청의 바깥에서 사용하려고 했기 때문이다.)

세션에 접근하고 수정하기¶

때로는 테스트 클라이언트에서 세션에 접근하고 수정하는 일은 매우 유용할 수 있다. 일반적으로 이를 위한 두가지 방법이 있다. 만약 세션이 특정 키 값으로 설정이 되어 있고 그 값이 컨텍스트를 통해서 유지 된다고 접근 가능한것을 보장하는 경우 flask.session:

with app.test_client() as c:
    rv = c.get('/')
    assert flask.session['foo'] == 42

그렇지만 이와 같은 경우는 세션을 수정하거나 접급하는 하는 것을 요청이 실행되기전에 가능하도록 해주지는 않는다. Flask 0.8 버전 부터는 “세션 트랜잭션(session transparent)” 이라고 부르는 세션에 대한 적절한 호출과 테스트 클라이언트에서의 수정이 가능한지 시뮬레이션이 가능하도록 하고 있다. 트랜잭션의 끝에서 해당 세션은 저장된다. 이것은 백엔드(backend)에서 사용되었던 세션과 독립적으로 작동가능하다.:

with app.test_client() as c:
    with c.session_transaction() as sess:
        sess['a_key'] = 'a value'

    # once this is reached the session was stored

이경우에 flask.session 프록시의 sess 객체를 대신에 사용하여야 함을 주의하자. 이 객체는 동일한 인터페이스를 제공한다.

메일로 에러 발송하기¶

만약 어플리케이션이 운영 모드에서 실행되고 있다면(여러분의 서버에서) 여러분은 기본으로 어떠한 로그 메세지도 보지 못할 것이다. 그건 왜일까? Flask는 설정이 없는 프레임워크가 되려고 노력한다. 만약 어떠한 설정도 없다면 Flask는 어디에 로그를 떨어뜨려야 하나? 추측은 좋은 아이디어가 아닌다. 왜냐하면 추측되어진 위치는 사용자가 로그 파일을 생성할 권한을 가지고 있는 위치가 아니기 때문이다.(?) 또한 어쨌든 대부분의 작은 어플리케이션에서는 아무도 로그 파일을 보지 않을 것이다.

사실 어플리케이션 에러에 대한 로그 파일을 설정한다하더라도 사용자가 이슈를 보고 했을 때 디버깅을 할 때를 제외하고 결코 로그 파일을 보지 않을 것이라는 것을 확신한다. 대신 여러분이 원하는 것은 예외가 발생했을 때 메일을 받는 것이다. 그리고 나서 여러분은 경보를 받고 그것에 대한 무언가를 할 수 있다.

Flask는 파이썬에 빌트인된 로깅 시스템을 사용한다. 실제로 에러가 발생했을 때 아마도 여러분이 원하는 메일을 보낸다. 아래는 예외가 발생했을 때 Flask 로거가 메일을 보내는 것을 설정하는 방법을 보여준다:

ADMINS = ['yourname@example.com']
if not app.debug:
    import logging
    from logging.handlers import SMTPHandler
    mail_handler = SMTPHandler('127.0.0.1',
                               'server-error@example.com',
                               ADMINS, 'YourApplication Failed')
    mail_handler.setLevel(logging.ERROR)
    app.logger.addHandler(mail_handler)

무슨 일이 일어났는가? 우리는 127.0.0.1 에서 리스닝하고 있는 메일 서버를 가지고 “YourApplication Failed”란 제목으로 server-error@example.com 송신자로부터 모든 관리자 에게 메일을 보내는 새로운 SMTPHandler 를 생성했다. 만약 여러분의 메일 서버가 자격을

요구한다면 그것들 또한 제공될 수 있다. 이를 위해 SMTPHandler 를 위한 문서를 확인해라.

우리는 또한 단지 에러와 더 심각한 메세지를 보내라고 핸들러에게 말한다. 왜냐하면 우리는 주의 사항이나 요청을 핸들링하는 동안 발생할 수 있는 쓸데없는 로그들을에 대한 메일을 받는 것을 원하지 않는다

여러분이 운영 환경에서 이것을 실행하기 전에, 에러 메일 안에 더 많은 정보를 넣기 위해 로그 포맷 다루기 챕터를 보아라. 그것은 많은 불만으로부터 너를 구해줄 것이다.

파일에 로깅하기¶

여러분이 메일을 받는다 하더라도, 여러분은 아마 주의사항을 로깅하기를 원할지도 모른다. 문제를 디버그하기 위해 요구되어질 수 있는 많은 정보를 많이 유지하는 것은 좋은 생각이다. Flask는 자체적으로 코어 시스템에서 어떠한 주의사항도 발생하지 않는다는 것을 주목해라. 그러므로 무언가 이상해 보일 때 코드 안에 주의사항을 남기는 것은 여러분의 책임이다.

로깅 시스템에 의해 제공되는 몇가지 핸들러가 있다. 그러나 기본 에러 로깅을 위해 그것들 모두가 유용한 것은 아니다. 가장 흥미로운 것은 아마 아래오 같은 것들일 것이다:

• FileHandler - 파일 시스템 내 파일에 메세지를 남긴다.
• RotatingFileHandler - 파일 시스템 내 파일에 메세지를 남기며 특정 횟수로 순환한다.
• NTEventLogHandler - 윈도 시스템의 시스템 이벤트 로그에 로깅할 것이다. 만약 여러분이 윈도에 디플로이를 한다면 이 방법이 사용하기 원하는 방법일 것이다.
• SysLogHandler - 유닉스 syslog에 로그를 보낸다.

일단 여러분이 로그 핸들러를 선택하면, 위에서 설명한 SMTP 핸들러를 가지고 여러분이 했던 더 낮은 레벨을 설정하는 것만 확인하라(필자는 WARNING을 추천한다.):

if not app.debug:
    import logging
    from themodule import TheHandlerYouWant
    file_handler = TheHandlerYouWant(...)
    file_handler.setLevel(logging.WARNING)
    app.logger.addHandler(file_handler)

로그 포맷 다루기¶

기본으로 해들러는 단지 파일 안에 메세지 문자열을 쓰거나 메일로 여러분에 메세지를 보내기만 할 것이다. 로그 기록은 더 많은 정보를 저장한다. 왜 에러가 발생했는니나 더 중요한 어디서 에러가 발생했는지 등의 더 많은 정보를 포함하도록 로거를 설정할 수 있다.

포매터는 포맷 문자열을 가지고 초기화될 수 있다. 자동으로 역추적이 로그 진입점에 추가되어진다는 것을 주목하라.(?) 여러분은 로그 포맷터 포맷 문자열안에 그걸 할 필요가 없다.

여기 몇가지 셋업 샘플들이 있다:

from logging import Formatter
mail_handler.setFormatter(Formatter('''
Message type:       %(levelname)s
Location:           %(pathname)s:%(lineno)d
Module:             %(module)s
Function:           %(funcName)s
Time:               %(asctime)s

Message:

%(message)s
'''))

from logging import Formatter
file_handler.setFormatter(Formatter(
    '%(asctime)s %(levelname)s: %(message)s '
    '[in %(pathname)s:%(lineno)d]'
))

다른 라이브러리들¶

이제까지는 우리는 단지 여러분의 어플리케이션이 생성한 로거를 설정했다. 다른 라이브러리들 또한 로그를 남길 수 있다. 예를 들면 SQLAlchemy가 그것의 코어 안에서 무겁게 로깅을 사용한다. logging 패키지 안에 모든 로거들을 설정할 방법이 있지만 나는 그거을 사용하는 것을 추천하지 않는다. 여러분이 같은 파이썬 인터프리터에서 같이 실행되는 여러 개로 분리된 어플리케이션을 갖기를 원할 수도 있다. 이러한 상황을 위해 다른 로깅을 셋업하는 것은 불가능하다.

대신 getLogger() 함수를 가지고 로거들을 얻고 핸들러를 첨부하기 위해 얻은 로거들을 반복하여 여러분이 관심있어 하는 로거들을 만드는 것을 추천한다:

from logging import getLogger
loggers = [app.logger, getLogger('sqlalchemy'),
           getLogger('otherlibrary')]
for logger in loggers:
    logger.addHandler(mail_handler)
    logger.addHandler(file_handler)

의심이 들때는 수동으로 실행하자¶

제품화를 위해 설정된 어플리케이션에서 문제를 겪고 있는가? 만약 해당 호스트에 쉘 접근 권한을 가지고 있다면, 배포 환경에서 쉘을 이용해 수동으로 어플리케이션을 실행 할 수 있는지 확인한다. 권한에 관련된 문제를 해결하기 위해서는 배포환경에 설정된 것과 동일한 사용자 계정에서 실행되어야 한다. 제품화된 운영 호스트에서 debug=True 를 이용하여 Flask에 내장된 개발 서버를 사용하면 설정 문제를 해결하는데 도움이되지만, 이와같은 설정은 통제된 환경에서 임시적으로만 사용해야 함을 명심하자. debug=True 설정은 운영환경 혹은 제품화되었을때는 절대 사용해서는 안된다.

디버거로 작업하기¶

좀더깊이 들어가서 코드 실행을 추적한다면, Flask는 독자적인 디버거를 제공한다. (디버그 모드 참고) 만약 또다른 Python 디버거를 사용하고 싶다면 이 디버거들은 서로 간섭현상이 발생하므로 주의가 필요하다. 선호하는 디버거를 사용하기 위해서는 몇몇 디버깅 옵션을 설정해야만 한다.:

• debug - 디버그 모드를 사용하고 예외를 잡을 수 있는지 여부
• use_debugger - Flask 내부 디버거를 사용할지 여부
• use_reloader - 예외발생시 프로세스를 포크하고 리로드할지 여부

debug 옵션은 다른 두 옵션 이 어떤값을 갖던지 반드시 True 이어야 한다. (즉, 예외는 잡아야만 한다.)

만약 Eclipse에서 Aptana를 디버깅을 위해 사용하고 싶다면, use_debugger` 와 `use_reloader 옵션을 False로 설정해야 한다.

config.yaml을 이용해서 다음과 같은 유용한 설정패턴을 사용하는 것이 가능하다 (물론 자신의 어플리케이션을위해 적절하게 블럭안의 값들을 변경시킬 수 있다.):

FLASK:
    DEBUG: True
    DEBUG_WITH_APTANA: True

이렇게 설정한다음 어플리케이션의 시작점(main.py)에 다음과 같이 사용할 수 있다.:

if __name__ == "__main__":
    # To allow aptana to receive errors, set use_debugger=False
    app = create_app(config="config.yaml")

    if app.debug: use_debugger = True
    try:
        # Disable Flask's debugger if external debugger is requested
        use_debugger = not(app.config.get('DEBUG_WITH_APTANA'))
    except:
        pass
    app.run(use_debugger=use_debugger, debug=app.debug,
            use_reloader=use_debugger, host='0.0.0.0')

설정 기초연습¶

config 은 실제로는 dictionary 의 서브클래스이며, 다른 dictionary 처럼 다음과 같이 수정될 수 있다:

app = Flask(__name__)
app.config['DEBUG'] = True

확정된 설정값들은 또한 Flask 객체로 전달될 수 있으며, 그 객체를 통해 설정값들을 읽거나 쓸수 있다.

app.debug = True

한번에 다수의 키(key)들을 업데이트 하기 위해서는 dict.update() 함수를 사용 할 수 있다.

app.config.update(
    DEBUG=True,
    SECRET_KEY='...'
)

내장된 고유 설정값들¶

다음의 설정값들은 Flask 의 내부에서 이미 사용되고 있는 것들이다. :

파일을 통하여 설정하기¶

만약 설정을 실제 어플리케이션 패키지의 바깥쪽에 위치한 별도의 파일에 저장할 수 있다면 좀더 유용할 것이다. 이것은 어플리케이션의 패키징과 배포단계에서 다양한 패키지 도구 (Distribute으로 전개하기) 들을 사용할 수 있도록 해주며, 결과적으로 사후에 설정 파일을 수정 할 수 있도록 해준다.

일반적인 패턴은 다음과 같다:

app = Flask(__name__)
app.config.from_object('yourapplication.default_settings')
app.config.from_envvar('YOURAPPLICATION_SETTINGS')

이 예제 첫부분에서 설정 파일을 yourapplication.default_settings 모듈로부터 불러 온 다음 환경설정 값들을 YOURAPPLICATION_SETTINGS 파일의 내용으로 덮어씌운다. 이 환경 변수들은 리눅스(Linux) 혹은 OS X 에서는 서버를 시작하기 전에 쉘의 export 명령어로 설정 할 수도 있다:

$ export YOURAPPLICATION_SETTINGS=/path/to/settings.cfg
$ python run-app.py
 * Running on http://127.0.0.1:5000/
 * Restarting with reloader...

윈도우 시스템에서는 내장 명령어인 set 을 대신 사용할 수 있다:

>set YOURAPPLICATION_SETTINGS=\path\to\settings.cfg

설정 파일들은 실제로는 파이썬 파일들이다. 오직 대문자로된 값들만 나중에 실제로 설정 객체에 저장된다. 그래서 반드시 설정 키값들은 대문자를 사용하여야 한다.

여기 설정 파일에 대한 예제가 있다:

# Example configuration
DEBUG = False
SECRET_KEY = '?\xbf,\xb4\x8d\xa3"<\x9c\xb0@\x0f5\xab,w\xee\x8d$0\x13\x8b83'

아주 초기에 설정을 로드 할수 있도록 확신할 수 있어야 하고, 확장(플러그인)들은 실행시점에 설정에 접근 할 수 있다. 설정 객체에서 뿐만 아니라 개별 파일에서도 역시 로드할 수 있는 방법이 존재 한다. 완전한 참고를 위해 Config 객체에 대한 문서를 읽으면 된다.

설정 베스트 사례¶

앞에서 언급한 접근 방법들에 대한 단점은 테스트를 좀더 확실히 해야 한다는 것이다. 이 문제에 대해서 일반적인 100%의 단일 해법은 존재하지 않는다. 하지만, 이러한 경험을 개선하기 위해 여두해 두어야 할 몇가지가 있다:

1. 여러분의 어플리케이션을 함수에 구현하고 (Flask의) 블루프린트에 등록하자. 이러한 방법을 통해 어플리케이션에 대해서 다중인스턴스를 생성하여 유닛테스트를 보다 쉽게 진행 할 수 있다. 필요에 따라 설정값을 전달해주기 위해 이 방법을 사용할 수 있다.
2. 임포트 시점에 설정정보를 필요로 하는 코드를 작성하지 않는다. 만약 여러분이 스스로 설정값에 대해서 오직 요청만 가능하도록 접근을 제한 한다면 필요에 의해 나중에 설정 객체를 재설정 할 수 있다.

개발 / 운영(혹은 제품)¶

대부분의 어플리케이션은 하나 이상의 설정(구성)이 필요 하다. 적어도 운영 환경과 개발환경은 독립된 설정값을 가지고 있어야만 한다. 이것을 다루는 가장 쉬운 방법은 버전 관리를 통하여 항상 로드되는 기본 설정값을 사용하는 것이다. 그리고 독립된 설정을값들을 필요에 따라 위에서 언급했던 방식으로 덮어쓰기한다:

app = Flask(__name__)
app.config.from_object('yourapplication.default_settings')
app.config.from_envvar('YOURAPPLICATION_SETTINGS')

그런다음, 여러분은 단지 독립적인 config.py 파일을 추가한 후 YOURAPPLICATION_SETTINGS=/path/to/config.py 를 export 하면 끝난다. 물론 다른 방법들도 있다. 예를들면, import 혹은 상속과 같은 방법도 가능하다.

장고(Django)의 세계에서는 명시적으로 설정 파일을 from yourapplication.default_settings import import * 를 이용해 파일의 상단에 추가 하여 변경 사항은 수작업으로 덮어쓰기 하는 방법이 가장 일반적이다. 또한 YOURAPPLICATION_MODE 와 환경 변수에 대해서 production , development 등의 값을 조사하여 하드코드된 다른 값들을 import 할 수도 있다.

한가지 흥미로운 패턴은 설정에 대해서도 클래스와 상속을 사용할 수 있다는 것이다:

class Config(object):
    DEBUG = False
    TESTING = False
    DATABASE_URI = 'sqlite://:memory:'

class ProductionConfig(Config):
    DATABASE_URI = 'mysql://user@localhost/foo'

class DevelopmentConfig(Config):
    DEBUG = True

class TestingConfig(Config):
    TESTING = True

이와 같은 설정을 활성화하기 위해서는 단지 meth:~flask.Config.from_object:: 를 호출 하면 된다:

app.config.from_object('configmodule.ProductionConfig')

여기 많은 다양한 다른 방법이 있지만 이것은 여러분이 설정 파일을 어떻게 관리하기 원하는가에 달려 있다. 여기 몇가지 좋은 권고사항이 있다:

• 버전관리에서 기본 설정을 유지한다. 각각의 설정 파일을 이전할때에 이 기본 설정 파일을 사용하거나 설정 값을 덮어쓰기 전에 기본 설정 파일의 내용을 자신의 파일로 가져오기
• 설정 사이를 전환할 환경변수를 사용한다. 이방식은 파이썬 인터프리터 외부에서 수행하고 빠르고 쉽기 때문에 결국 코드를 만지지 않고도 다른 설정 사이를 전환 할 수 있기 때문에 개발 및 배포를 훨씬 쉽게 만들어 줄 수 있다. 만약 여러분이 종종 다른 프로젝트들에서 작업한다면, virtualenv를 구동하는 자신만의 스크립트를 생성하여 자신을 위한 개발 설정을 export 하여 사용할 수 있다.
• 코드와 설정을 독립된 운영 서버에 배포하기 위해서 fabric 과 같은 도구를 사용한다. 어떻게 할 수 있는지 자세한 내용은 다음의 내용을 참고 하면 된다. Fabric으로 전개하기 패턴

인스턴스 폴더¶

Flask 0.8 에서 임시 폴더가 도입되었다. 오랫시간동안 Flask는 가능한 어플리케이션에 대한 상대 경로를 직접 참조 할 수 있도록 해왔다( Flask.root_path 를 통해서). 이것을 통해 어플리케이션의 설정을 바로 옆에 저장하고 불러오는 많은 개발자들이 있었다. 하지만 불행하게도 이 방법은 오직 어플리케이션이 루트 경로가 패키지의 내용을 참고하지 않는 경우에만 잘 작동 한다.

Flask 0.8 부터 새로룬 속성이 도입 되었다: Flask.instance_path . 이 새로운 컨셉의 속성은 “인스턴스 폴더” 라고 불린다. 인스턴스 폴더는 버전 관리와 특정한 배포에 속하지 않도록 설계되었다. 인스턴스 폴더는 런타임에서의 변경 사항 혹은 설정 파일의 변경 사항에 대한 것들을 보관하기에 완벽한 장소이다.

여러분은 인스턴스 폴더의 경로에 대해 Flask 어플리케이션이 생성될 때 혹은 Flask가 인스턴스 폴더를 자동으로 탐지 하도록 하여 명백하게 제공 받을 수 있다 명시적인 설정으로 사용하기 위해서는 instance_path 파라미터를 쓸 수 있다:

app = Flask(__name__, instance_path='/path/to/instance/folder')

이때에 제공되는 폴더의 경로는 절대 경로임을 반드시 명심하자.

만약 instance_path 파라미터가 인스턴스 폴더를 제공하지 않는 다면 다음의 위치가 기본으로 사용된다:

• Uninstalled module:

  /myapp.py
  /instance
  

• Uninstalled package:

  /myapp
      /__init__.py
  /instance
  

• Installed module or package:

  $PREFIX/lib/python2.X/site-packages/myapp
  $PREFIX/var/myapp-instance
  

  $PREFIX 는 파이썬이 설치된 경로의 prefix 이다. 이 것은 /usr 혹은 여러분의 virtualenv 경로이다. sys.prefix 를 이용해서 현재 설정된 prefix를 출력해 볼 수 있다.

설정 객체가 설정 파일을 상대 경로로 부터 읽어 올 수 있도록 제공 하기 때문에 우리는 가능한 한 인스턴스 경로에 대한 상대 파일이름을 통해서 로딩을 변경했다. 설정파일이 있는 상대경로의 동작은 “relative to the application root” (디폴트)와 “relative to instance folder” 사이에서 instance_relative_config 어플리케이션 생성자에 의해 뒤바뀔 수 있다:

app = Flask(__name__, instance_relative_config=True)

여기 어떻게 Flask에서 모듈의 설정을 미리 로드하고 설정 폴더가 존재 할 경우 설정 파일로 부터 설정을 덮어쓰기 할 수 있는 전체 예제가 있다

app = Flask(__name__, instance_relative_config=True)
app.config.from_object('yourapplication.default_settings')
app.config.from_pyfile('application.cfg', silent=True)

인스턴스 폴더의 경로를 통해 Flask.instance_path 를 찾을 수 있다. Flask는 또한 인스턴스 폴더의 파일을 열기 위한 바로가기를 Flask.open_instance_resource() 를 통해 제공 한다.

두 경우에 대한 사용 예제:

filename = os.path.join(app.instance_path, 'application.cfg')
with open(filename) as f:
    config = f.read()

# or via open_instance_resource:
with app.open_instance_resource('application.cfg') as f:
    config = f.read()

시그널을 수신하기¶

시그널은 수신하려면 시그널의 connect() 메소드를 사용할 수 있다. 첫번째 인자는 시그널이 송신됐을 때 호출되는 함수고, 선택적인 두번째 인자는 송신자를 지정한다. 해당 시그널의 송신을 중단하려면 disconnect() 메소드를 사용하면 된다.

모든 핵심 플라스크 시그널에 대해서 송신자는 시그널을 발생하는 어플리케이션이다. 여러분이 시그널을 수신할 때, 모든 어플리케이션의 시그널을 수신하고 싶지 않다면 받고자하는 시그널의 송신자 지정을 잊지 말도록 해라. 여러분이 확장을 개발하고 있다면 특히나 주의해야한다.

예를 들면 여기에 단위테스팅에서 어떤 템플릿이 보여지고 어떤 변수가 템플릿으로 전달되는지 이해하기 위해 사용될 수 있는 헬퍼 컨택스트 매니저가 있다:

from flask import template_rendered
from contextlib import contextmanager

@contextmanager
def captured_templates(app):
    recorded = []
    def record(sender, template, context, **extra):
        recorded.append((template, context))
    template_rendered.connect(record, app)
    try:
        yield recorded
    finally:
        template_rendered.disconnect(record, app)

위의 메소드는 테스트 클라이언트와 쉽게 묶일 수 있다:

with captured_templates(app) as templates:
    rv = app.test_client().get('/')
    assert rv.status_code == 200
    assert len(templates) == 1
    template, context = templates[0]
    assert template.name == 'index.html'
    assert len(context['items']) == 10

플라스크가 시그널에 새 인자를 알려준다면 여러분이 호출한 메소드는 실패하지 않을 것이므로 추가적인 **extra 인자로 수신하도록 해라.

with 블럭의 내용에 있는 어플리케이션 app 이 생성한 코드에서 보여주는 모든 템플릿은 templates 변수에 기록될 것이다. 템플릿이 그려질 때마다 컨텍스트 뿐만 아니라 템플릿 객체도 어플리케이션에 덧붙여진다.

부가적으로 편리한 헬퍼 메소드도 존재한다(connected_to()). 그 메소드는 일시적으로 그 자체에 컨텍스트 메니저를 가진 시그널에 대한 함수를 수신한다. 컨텍스트 매니저의 반환값을 그런 방식으로 지정할 수 없기 때문에 인자로 템플릿의 목록을 넘겨줘야 한다:

from flask import template_rendered

def captured_templates(app, recorded, **extra):
    def record(sender, template, context):
        recorded.append((template, context))
    return template_rendered.connected_to(record, app)

위의 예제는 아래처럼 보일 수 있다:

templates = []
with captured_templates(app, templates, **extra):
    ...
    template, context = templates[0]

시그널 생성하기¶

여러분이 어플리케이션에서 시그널을 사용하고 싶다면, 직접 blinker 라이브러리를 사용할 수 있다. 가장 일반적인 사용예는 변경된 Namespace. 클래스에 시그널을 명명하는 것이다. 이것이 보통 권고되는 방식이다:

from blinker import Namespace
my_signals = Namespace()

이제 여러분은 아래와 같이 새 시그널을 생성할 수 있다:

model_saved = my_signals.signal('model-saved')

여기에서 시그널에 이름을 준것은 시그널은 구분해주고 또한 디버깅을 단순화한다. name 속성으로 시그널에 부여된 이름을 얻을 수 있다.

시그널 보내기¶

시그널을 전송하고 싶다면, send() 메소드를 호출하면 된다. 이 메소드는 첫번째 인자로 송신자를 넘겨주고 선택적으로 시그널 수신자에게 전달되는 키워드 인자도 있다:

class Model(object):
    ...

    def save(self):
        model_saved.send(self)

항상 좋은 송신자를 뽑도록 한다. 여러분이 시그널을 보내는 클래스를 갖는다면 송신자로 self 를 넘겨준다. 여러분이 임의의 함수에서 시그널을 전송한다면, current_app._get_current_object() 를 송신자로 전달할 수 있다.

시그널과 플라스크 요청 컨텍스트¶

시그널을 수신할 때 요청 컨텍스트 를 완전하게 지원한다. Context-local 변수는 request_started 과 request_finished 사이에서 일관성을 유지하므로 여러분은 필요에 따라 flask.g 과 다른 변수를 참조할 수 있다. 시그널 보내기 과 request_tearing_down 시그널에서 언급하는 제약에 대해 유의한다.

시그널 수신 기반 데코레이터¶

Blinker 1.1 과 함께 여러분은 또한 connect_via() 데코레이터를 사용하여 시그널을 쉽게 수신할 수 있다:

from flask import template_rendered

@template_rendered.connect_via(app)
def when_template_rendered(sender, template, context, **extra):
    print 'Template %s is rendered with %s' % (template.name, context)

핵심 시그널¶

플라스크에는 다음과 같은 시그널이 존재한다:

flask.template_rendered

이 시그널은 템플릿이 성공적으로 뿌려졌을 때 송신된다. 이 시그널은 template 으로 템플릿과 딕셔너리 형태인 context 로 컨텍스트를 인스턴스로 하여 호출된다.

수신 예제:

def log_template_renders(sender, template, context, **extra):
    sender.logger.debug('Rendering template "%s" with context %s',
                        template.name or 'string template',
                        context)

from flask import template_rendered
template_rendered.connect(log_template_renders, app)

flask.request_started

이 시그널은 요청 처리가 시작되기 전이지만 요청 컨텍스트는 만들어졌을 때 송신된다. 요청 컨텍스트가 이미 연결됐기 때문에, 수신자는 표준 전역 프록시 객체인 request 으로 요청을 참조할 수 있다.

수신 예제:

def log_request(sender, **extra):
    sender.logger.debug('Request context is set up')

from flask import request_started
request_started.connect(log_request, app)

flask.request_finished

이 시그널은 클라이언트로 응답이 가기 바로 전에 보내진다. response 인자로 응답 객체를 넘겨준다.

수신 예제:

def log_response(sender, response, **extra):
    sender.logger.debug('Request context is about to close down.  '
                        'Response: %s', response)

from flask import request_finished
request_finished.connect(log_response, app)

flask.got_request_exception

이 시그널은 요청 처리 동안 예외가 발생했을 때 보내진다. 표준 예외처리가 시작되기 전에 송신되고 예외 처리를 하지 않는 디버깅 환경에서도 보내진다. exception 인자로 예외 자체가 수신자에게 넘어간다.

수신 예제:

def log_exception(sender, exception, **extra):
    sender.logger.debug('Got exception during processing: %s', exception)

from flask import got_request_exception
got_request_exception.connect(log_exception, app)

flask.request_tearing_down

이 시그널은 요청 객체가 제거될 때 보내진다. 요청 처리 과정에서 요류가 발생하더라도 항상 호출된다. 현재 시그널을 기다리고 있는 함수는 일반 teardown 핸들러 뒤에 호출되지만, 순서를 보장하지는 않는다.

수신 예제:

def close_db_connection(sender, **extra):
    session.close()

from flask import request_tearing_down
request_tearing_down.connect(close_db_connection, app)

플라스크 0.9에서, 예외가 있는 경우 이 시그널을 야기하는 예외에 대한 참조를 갖는 ‘exc’ 키워드 인자를 또한 넘겨줄 것이다.

flask.appcontext_tearing_down

이 시그널은 어플리케이션 컨텍스트가 제거될 때 보내진다. 예외가 발생하더라도 이 시그널은 항상 호출되고, 일반 teardown 핸들러 뒤에 시그널에 대한 콜백 함수가 호출되지만, 순서는 보장하지 않는다.

수신 예제:

def close_db_connection(sender, **extra):
    session.close()

from flask import appcontext_tearing_down
appcontext_tearing_down.connect(close_db_connection, app)

‘request_tearing_down’ 과 마찬가지로 예외에 대한 참조를 exc 키워드 인자로 넘겨줄 것이다.

기본 원칙(Basic Principle)¶

여러분이 데이타베이스에서 어떤 객체의 목록을 읽어서 템플릿에 보여주는 함수를 가진다고 고려해보자:

@app.route('/users/')
def show_users(page):
    users = User.query.all()
    return render_template('users.html', users=users)

위의 코드는 간단하고 유연하지만, 여러분이 다른 모델이나 템플릿에도 적용가능한 일반적인 방식으로 이 뷰를 제공하고 싶다면 더 유연한 구조를 원할지 모른다. 이 경우가 끼워넣을 수 있는 클래스를 기반으로 한 뷰가 적합한 곳이다. 클래스 기반의 뷰로 변환하기 위한 첫 단계는 아래와 같다.

from flask.views import View

class ShowUsers(View):

    def dispatch_request(self):
        users = User.query.all()
        return render_template('users.html', objects=users)

app.add_url_rule('/users/', view_func=ShowUsers.as_view('show_users'))

위에서 볼 수 있는 것처럼, 여러분은 flask.views.View 의 서브클래스를 만들고 dispatch_request() 를 구현해야한다. 그리고 그 클래스를 as_view() 클래스 메소드를 사용해서 실제 뷰 함수로 변환해야한다.

그 함수로 전달하는 문자열은 뷰가 가질 끝점(end-point)의 이름이다. 위의 코드를 조금 리팩토링해보자.

from flask.views import View

class ListView(View):

    def get_template_name(self):
        raise NotImplementedError()

    def render_template(self, context):
        return render_template(self.get_template_name(), **context)

    def dispatch_request(self):
        context = {'objects': self.get_objects()}
        return self.render_template(context)

class UserView(ListView):

    def get_template_name(self):
        return 'users.html'

    def get_objects(self):
        return User.query.all()

물론 이것은 이런 작은 예제에서는 그다지 도움이 안될 수도 있지만, 기본 원칙을 설명하기에는 충분하다. 여러분이 클래스 기반의 뷰를 가질 때, self 가 가리키는 건 무엇이냐는 질문이 나온다. 이것이 동작하는 방식은 요청이 들어올 때마다 클래스의 새 인스턴스가 생성되고 dispatch_request() 메소드가 URL 규칙으로부터 나온 인자를 가지고 호출된다. 클래스 그 자체로는 as_view() 함수에 넘겨지는 인자들을 가지고 인스턴스화된다. 예를 들면, 아래와 같은 클래스를 작성할 수 있다:

class RenderTemplateView(View):
    def __init__(self, template_name):
        self.template_name = template_name
    def dispatch_request(self):
        return render_template(self.template_name)

그런 다음에 여러분은 아래와 같이 뷰 함수를 등록할 수 있다:

app.add_url_rule('/about', view_func=RenderTemplateView.as_view(
    'about_page', template_name='about.html'))

메소드 힌트¶

끼워넣을수 있는 뷰는 route() 나 더 낫게는 methods() 속성 정보를 제공할 수 있다:

class MyView(View):
    methods = ['GET', 'POST']

    def dispatch_request(self):
        if request.method == 'POST':
            ...
        ...

app.add_url_rule('/myview', view_func=MyView.as_view('myview'))

메소드 기반 디스패치¶

RESTful API에서 각 HTTP 메소드별로 다른 함수를 수행하는 것은 굉장히 도움이 된다. flask.views.MethodView 로 여러분은 그 작업을 쉽게 할 수 있다. 각 HTTP 메소드는 같은 이름을 가진 함수(소문자)로 연결된다.

from flask.views import MethodView

class UserAPI(MethodView):

    def get(self):
        users = User.query.all()
        ...

    def post(self):
        user = User.from_form_data(request.form)
        ...

app.add_url_rule('/users/', view_func=UserAPI.as_view('users'))

이 방식은 또한 여러분이 methods 속성을 제공하지 않아도 된다. 클래스에 정의된 메소드 기반으로 자동으로 설정된다.

데코레이팅 뷰¶

뷰 클래스 그 자체는 라우팅 시스템에 추가되는 뷰 함수가 아니기 때문에, 클래스 자체를 데코레이팅하는 것은 이해되지 않는다. 대신, 여러분이 수동으로 as_view() 함수의 리턴값을 데코레이팅해야한다:

def user_required(f):
    """Checks whether user is logged in or raises error 401."""
    def decorator(*args, **kwargs):
        if not g.user:
            abort(401)
        return f(*args, **kwargs)
    return decorator

view = user_required(UserAPI.as_view('users'))
app.add_url_rule('/users/', view_func=view)

플라스크 0.8부터 클래스 선언에도 적용할 데코레이터 목록을 표시할 수 있는 대안이 있다:

class UserAPI(MethodView):
    decorators = [user_required]

호출하는 입장에서 그 자체로 암시적이기 때문에 여러분이 뷰의 개별 메소드에 일반적인 뷰 데코레이터를 사용할 수 없다는 것을 명심하길 바란다.

메소드 뷰 API¶

웹 API는 보통 HTTP 메소드와 매우 밀접하게 동작하는데 MethodView 기반의 API를 구현할때는 더욱 의미가 들어맞는다. 그렇긴 하지만, 여러분은 그 API가 대부분 같은 메소드 뷰로 가는 여러 다른 URL 규칙을 요구할 것이라는 것을 알아야 할 것이다. 예를 들면, 여러분이 웹에서 사용자 객체에 노출된 상황을 고려해보자:

그렇다면 MethodView 를 가지고는 어떻게 위와 같은 작업을 계속할 것인가? 여러분이 같은 뷰에 여러 규칙을 제공할 수 있는 것이 요령이다.

뷰가 아래와 같이 보일 때를 가정해보자:

class UserAPI(MethodView):

    def get(self, user_id):
        if user_id is None:
            # return a list of users
            pass
        else:
            # expose a single user
            pass

    def post(self):
        # create a new user
        pass

    def delete(self, user_id):
        # delete a single user
        pass

    def put(self, user_id):
        # update a single user
        pass

그렇다면 우리는 이것을 어떻게 라우팅 시스템으로 연결하는가? 두가지 규칙을 추가하고 명시적으로 각 메소드를 언급한다:

user_view = UserAPI.as_view('user_api')
app.add_url_rule('/users/', defaults={'user_id': None},
                 view_func=user_view, methods=['GET',])
app.add_url_rule('/users/', view_func=user_view, methods=['POST',])
app.add_url_rule('/users/<int:user_id>', view_func=user_view,
                 methods=['GET', 'PUT', 'DELETE'])

여러분이 유사하게 보이는 여러 API를 갖고 있다면, 등록하는 메소드를 추가하도록 아래처럼 리팩토링할 수 있다:

def register_api(view, endpoint, url, pk='id', pk_type='int'):
    view_func = view.as_view(endpoint)
    app.add_url_rule(url, defaults={pk: None},
                     view_func=view_func, methods=['GET',])
    app.add_url_rule(url, view_func=view_func, methods=['POST',])
    app.add_url_rule('%s<%s:%s>' % (url, pk_type, pk), view_func=view_func,
                     methods=['GET', 'PUT', 'DELETE'])

register_api(UserAPI, 'user_api', '/users/', pk='user_id')

어플리케이션 컨텍스트의 목적¶

어플리케이션의 컨텍스트가 존재하는 주요한 이유는 과거에 다수의 기능이 더 나은 솔루션의 부족으로 요청 컨텍스트에 덧붙여있었다는 것이다. Flask의 기본 설계 중 하나는 여러분이 같은 파이썬 프로세스에 하나 이상의 어플리케이션을 갖을 수 있다는 것이다.

그래서 코드는 어떻게 “적합한” 어플리케이션을 찾을 수 있는가? 과거에 우리는 명시적으로 어플리케이션을 제공했었지만, 그 방식은 명시적 전달을 염두하지 않은 라이브러리와 문제를 야기했다.

그 문제의 일반적인 차선책은 현재 요청에 대한 어플리케이션 참조와 연결되있는 current_app 프록시를 나중에 사용하는 것이었다. 그러나, 그런 요청 컨텍스트를 생성하는 것은 어떤 요청도 없는 경우에 불필요하게 고비용 동작이기 때문에, 그 어플리케이션 컨텍스트가 소개되었다.

어플리케이션 컨텍스트 생성하기¶

어플리케이션 컨텍스트를 만들기 위해서는 두 가지 방법이 있다. 첫번째는 임의적인 방식으로, 요청 컨텍스트가 들어올 때마다, 어플리케이션 컨텍스트가 필요한 경우 바로 옆에 생성될 것이다. 그 결과로 여러분은 어플리케이션 컨텍스트가 필요없다면 그 존재를 무시할 수 있다.

두 번째 방식은 app_context() 메소드를 사용하는 명시적으로 방법이다:

from flask import Flask, current_app

app = Flask(__name__)
with app.app_context():
    # within this block, current_app points to app.
    print current_app.name

어플리케이션 문맥은 SERVER_NAME 이 설정된 경우 url_for() 함수에 의해서도 사용된다. 이것은 요청이 없는 경우에도 여러분이 URL을 생성할 수 있게 해준다.

컨텍스트의 지역성¶

어플리케이션 문맥은 필요에 따라 생성되고 소멸된다. 그것은 결코 쓰레드들 사이를 이동할 수 없고 요청 사이에서 공유되지 않을 것이다. 그와 같이, 어플리케이션 문맥은 데이타베이스 연결 정보와 다른 정보들을 저장하는 최적의 장소다. 내부 스택 객체는 flask._app_ctx_stack 이다. 확장들은 충분히 구별되는 이름을 선택하다는 가정하에서 자유롭게 가장 상위에 추가적인 정보를 저장한다.

더 많은 정보에 대해서는 Flask Extension Development 을 살펴보라.

컨텍스트 사용¶

컨텍스트는 일반적으로 요청당 하나씩 생성되거나 직접 사용하는 경우에 캐시 리소스에 사용된다. 예를 들어 데이터베이스 연결과 같은 경우다. 어플리케이션 컨텍스트에 저장할 때에는 반드시 고유한 이름을 선택하여야 한다. 이 영역은 Flask 어플리케이션들과 확장(플러그인 같은)들에서 공유되기 때문이다.

가장 일반적인 사용법은 리소스 관리를 두개의 파트로 나누는 것이다:

1. 컨텍스트에서의 암시적인 자원 캐시
2. 컨텍스트 분해를 통한 리소스 할당 해제

일반적으로 자원 X 를 생성하는 get_X() 함수가 있다고 하자. 만약 그것이 아직 존재 하지 않고, 다른 방법으로 같은 자원을 반환하는 teardown_X() 함수가 teardown 핸들러에 등록되어 있다.

여기 데이터베이스에 연결하는 예제가 있다:

import sqlite3
from flask import _app_ctx_stack

def get_db():
    top = _app_ctx_stack.top
    if not hasattr(top, 'database'):
        top.database = connect_to_database()
    return top.database

@app.teardown_appcontext
def teardown_db(exception):
    top = _app_ctx_stack.top
    if hasattr(top, 'database'):
        top.database.close()

처음 get_db() 가 호출된 시점에 연결이 이루어진다. 이 것을 암시적으로 만들기 위해서는 LocalProxy 를 사용할 수 있다:

from werkzeug.local import LocalProxy
db = LocalProxy(get_db)

이것은 사용자가 ``db``에 내부 호출인 ``get_db()``를 통해서 직접 접근 가능하게 해준다.

컨텍스트 로컬로 다이빙하기¶

여러분이 사용자를 리디렉트해야하는 URL을 반환하는 유틸리티 함수를 갖는다고 하자. 그 함수는 항상 URL의 next 인자나 HTTP referer 또는 index에 대한 URL을 리디렉트한다고 가정하자:

from flask import request, url_for

def redirect_url():
    return request.args.get('next') or \
           request.referrer or \
           url_for('index')

여러분이 볼 수 있는 것처럼, 그것은 요청 객체를 접근한다. 여러분은 플레인 파이썬 쉘에서 이것을 실행하면, 여러분은 아래와 같은 예외를 볼 것이다:

>>> redirect_url()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'request'

우리가 현재 접근할 수 있는 요청을 갖고 있지 않기 때문에 그것은 이해가 된다. 그래서 우리는 요청을 만들고 그것을 현재 컨텍스트에 연결시켜야 한다. test_request_context 메소드는 우리에게 RequestContext 를 만들어 줄 수 있다:

>>> ctx = app.test_request_context('/?next=http://example.com/')

이 컨텍스트는 두 가지 방식으로 사용될 수 있다. with 절과 함께 사용되거나 push() 와 pop() 메소드를 호출하여 사용된다:

>>> ctx.push()

이 시점부터 여러분은 요청 객체를 가지고 작업할 수 있다 :

>>> redirect_url()
u'http://example.com/'

pop 함수를 호출할 때까지:

>>> ctx.pop()

요청 컨텍스트는 내부적으로 스택을 유지하기 때문에 여러분은 여러번 push와 pop을 할 수 있다. 이것이 내부적인 리디렉트와 같은 것을 손쉽게 구현한 것이다.

상호작용 파이썬 쉘로부터 요청 컨텍스트를 사용하는 더 많은 정보는 쉘에서 작업하기 장으로 넘어가라.

컨텍스트가 작동하는 방식¶

여러분이 플라스크 WSGI 어플리케이션이 내부적으로 동작하는 방식을 살펴보려면, 아래와 대단히 유사한 코드를 찾게될 것이다:

def wsgi_app(self, environ):
    with self.request_context(environ):
        try:
            response = self.full_dispatch_request()
        except Exception, e:
            response = self.make_response(self.handle_exception(e))
        return response(environ, start_response)

request_context() 메소드는 새로운 RequestContext 객체를 반환하고 컨텍스트를 연결하기 위해 with 구문과 조합하여 RequestContext 객체를 사용한다. 이 시점부터 with 구문의 끝까지 같은 쓰레드에서 호출되는 모든 것은 요청 글로벌 객체( flask.request 와 기타 다른것들)에 접근할 수 있을 것이다.

요청 컨텍스트도 내부적으로 스택처럼 동작한다. 스택의 가장 상위에는 현재 활성화된 요청이 있다. push() 는 스택의 제일 위에 컨텍스트를 더하고, pop() 은 스택으로부터 제일 상위에 있는 컨텍스트를 제거한다. 컨텍스트를 제거하는 pop 동작 시, 어플리케이션의 teardown_request() 함수 또한 실행된다.

주목할 다른 것은 요청 컨텍스트가 들어오고 그때까지 해당 어플리케이션에 어떠한 어플리케이션 컨텍스트가 없었다면, 자동으로 application context 또한 생성할 것이라는 것이다.

콜백과 오류¶

Flask에서 요청 처리하는 동안 오류가 발생하면 어떻게 되는가? 버전 0.7에서 이 특별한 동작이 변경되었는데, 왜냐하면 우리가 실제로 발생하는 것이 무엇인지 좀 더 쉽게 이해가기 원했기 때문이다:

1. 각 요청 전에, before_request() 함수들이 수행된다. 이런 함수들 중 하나라도 응답을 반환하면, 다른 함수들은 더 이상 호출되지 않는다. 그러나 어떤 경우라도 반환값은 뷰의 반환값에 대한 대체값으로 처리된다.
2. before_request() 함수들이 응닶을 반환하지 않는다면, 보통 요청 처리가 시작되고 요청에 맞는 뷰 함수가 응답을 반환하게 된다.
3. 그리고 나서, 뷰의 반환값은 실제 응답 객체로 변환되고 응답 객체를 대체하거나 변경할 준비가 되있는 after_request() 함수로 전달된다.
4. 요청의 종료 시에는 teardown_request() 함수가 실행된다. 이 함수는 심지어 처리되지 않는 예외의 경우나 before-request 핸들러가 아직 처리되지 않거나 전혀 실해되지 않는 경우에도 항상 발생한다. (예를 들면, 테스트 환경에서 때때로 before-request 콜백이 호출되지 않기를 원할수도 있다.)

자 오류가 발생하면 무슨일이 발생하는가? 운영 환경에서는 예외가 처리되지 않으면, 500 내부 서버 핸들러가 실행된다. 그러나, 개발 환경에서는 예외는 더 진행되지 않고 WSGI 서버로 영향을 미친다. 대화형 디버거와 같은 방식에서는 도움되는 디버깅 정보를 제공할 수 있다.

버전 0.7에서 중요한 변화는 내부 서버 오류가 더 이상 after-request 콜백에 의해 사후 처리되지 않고 after-request 콜백이 실행되는 것을 보장해주지 않는다는 것이다. 이 방식으로 내부 디스패칭 코드는 더 깔끔해졌고 커스터마이징과 이해가 더 쉬워졌다.

새로운 teardown 함수는 요청의 마지막에서 반드시 행이 필요한 경우에 대체할 목적으로 사용되는 것을 가정한다.

테어다운(Teardown) 콜백¶

테어다운 콜백은 특별한 콜백인데 여러 다른 시점에 실행되기 때문이다. 엄격하게 말하자면, 그것들이 RequestContext 객체의 생명주기와 연결되있긴 하지만, 그것들은 실제 요청 처리와 독립되있다. 요청 문맥이 꺼내질 때, teardown_request() 함수는 호출된다.

with 구문이 있는 테스트 클라이언트를 사용하여 요청 문맥의 생명이 범위가 늘었는지 또는 명령줄에서 요청 문맥을 사용할 때를 아는 것이 중요하다:

with app.test_client() as client:
    resp = client.get('/foo')
    # the teardown functions are still not called at that point
    # even though the response ended and you have the response
    # object in your hand

# only when the code reaches this point the teardown functions
# are called.  Alternatively the same thing happens if another
# request was triggered from the test client

명령줄에서 이 동작을 보기는 쉽다.:

>>> app = Flask(__name__)
>>> @app.teardown_request
... def teardown_request(exception=None):
...     print 'this runs after request'
...
>>> ctx = app.test_request_context()
>>> ctx.push()
>>> ctx.pop()
this runs after request
>>>

before-request 콜백은 아직 실행되지 않고 예외가 발생했더라도,teardown 콜백은 항상 호출된다는 것을 명심하라. 테스트 시스템의 어떤 부분들 또한 before-request 핸들러를 호출하지 않고 일시적으로 요청 문맥을 생성할지도 모른다. 절대로 실패하지 않는 방식으로 여러분의 teardown-request 핸들러를 쓰는 것을 보장하라.

프록시에서 주의할 점¶

플라스크에서 제공하는 일부 객체들은 다른 객체에 대한 프록시들이다. 이렇게 하는 뒷 배경에는 이런 프락시들이 쓰레들간에 공유되어 있고 그 프락시들이 쓰레드들에 연결된 실제 객체로 필요시에 보이지 않게 디스패치되어야 한다는 것이다.

대게 여러분은 그 프락시에 대해서 신경쓰지 않아도 되지만, 이 객체가 실제 프락시인지 알면 좋은 몇 가지 예외의 경우가 있다. :

• 프락시 객체들이 상속받은 타입을 속이지 않아서, 여러분이 실제 인스턴스를 확인한다면, 프락시로 된 인스턴스에서 타입을 확인해야한다.(아래의 _get_current_object 를 보라).
• 객체의 참조가 중요한 경우( 시그널(Signals) 을 보내는 경우)

여러분이 프록시된 감춰진 객체에 접근할 필요가 있다면, _get_current_object() 메소드를 사용할 수 있다:

app = current_app._get_current_object() my_signal.send(app)

오류 시 컨텍스트 보존¶

오류가 발생하거나 하지 않거나, 요청의 마지막에서 요청 문맥은 스택에서 빠지게 되고 그 문맥과 관련된 모든 데이타는 소멸된다. 하지만, 개발하는 동안 그것은 예외가 발생하는 경우에 여러분이 더 오랜 시간동안 그 정보를 갖고 있기를 원하기 때문에 문제가 될 수 있다. 플라스크 0.6과 그 이전 버전의 디버그 모드에서는 예외가 발생했을 때, 요청 문맥이 꺼내지지 않아서 인터렉티브( 상호작용하는) 디버거가 여러분에게 여전히 중요한 정보를 제공할 수 있었다.

플라스크 0.7부터 여러분은 PRESERVE_CONTEXT_ON_EXCEPTION 설정 변수값을 설정하여 그 행동을 좀 더 세밀하게 설정한다. 디폴트로 이 설정은 DEBUG 설정과 연결된다. 어플리케이션이 디버그 모드라면, 그 문맥은 보존되지만, 운영 모드라면 보존되지 않는다.

어플리케이션이 예외 발생 시 메모리 누수를 야기할 수 있으므로 운영 모드에서 ``PRESERVE_CONTEXT_ON_EXCEPTION``을 강제로 활성화하지 않아야 한다. 하지만, 개발 모드에서 운영 설정에서만 발생하는 오류를 디버그하려 할 때 개발 모드로 같은 오류 보존 동작을 얻는 것은 개발하는 동안에는 유용할 수 있다.

왜 블루프린트인가?¶

플라스크의 블루프린트는 다음 경우로 인해 만들어졌다:

• 어플리케이션을 블루프린트의 집합으로 고려한다. 이 방식은 대형 어플리케이션에 있어서 이상적이다; 프로젝트는 어플리케이션 객체를 인스턴스화하고, 여러 확장을 초기화하고, 블루프린트의 묶음을 등록할 수 있다.
• 어플리케이션 상에 URL 접두어와/또는 서브도메인으로 블루프린트를 등록한다. URL 접두어와/또는 서브도메인에 있는 파라메터는 블루프린트에 있는 모든 뷰 함수에 걸쳐있는 공통 뷰 인자(기본값을 가진)가 된다.
• 어플리케이션에 여러 URL 규칙을 가진 블루프린트를 여러번 등록한다.
• 블루프린트를 통해 템플릿 필터, 정적 파일, 템플릿, 그리고 다른 유틸리티를 제공한다. 블루프린트는 어플리케이션이나 뷰 함수를 구현하지 않아도 된다.
• 플라스크 확장을 초기화할 때 이런 경우 중 어떤 경우라도 어플리케이션에 블루프린트를 등록한다.

플라스크에 있는 블루프린트는 끼우고 뺄수 있는 앱이 아니다 왜냐하면 블루프린트는 실제 어플리케이션이 아니기 때문이다 – 그것은 어플리케이션에 등록될 수 있는 동작의 집합인데 심지어 여러번 등록될 수 있다. 왜 복수의 어플리케이션 객체를 가지지 않는가? 여러분은 그렇게(어플리케이션 디스패칭 을 살펴봐라)할 수 있지만, 어플리케이션은 분리된 설정을 가질것 이고 WSGI 계층에서 관리될 것이다.

대신에 블루프린트는 플라스크 레벨에서 분리를 제공하고, 어플리케이션 설정을 공유하며 , 그리고 등록된 것을 가지고 필요에 따라 어플리케이션 객체를 변경할 수 있다. 이것의 단점은 일단 전체 어플리케이션 객체를 제거할 필요없이 어플리케이션이 생성됐을 때 여러분은 블루프린트를 해지할 수 없다.

블루프린트의 개념¶

블루프린트의 기본 개념은 어플리케이션에 블루프린트이 등록될 때 실행할 동작을 기록한다는 것이다. 플라스크는 요청을 보내고 하나의 끝점에서 다른 곳으로 URL을 생성할 때 뷰 함수와 블루프린트의 연관을 맺는다.

첫번째 블루프린트¶

아래는 가장 기본적인 블루프린트의 모습이다. 이 경우에 우리는 정적 템플릿을 간단하게 그려주는 블루프린트를 구현하기를 원할 것이다:

from flask import Blueprint, render_template, abort
from jinja2 import TemplateNotFound

simple_page = Blueprint('simple_page', __name__,
                        template_folder='templates')

@simple_page.route('/', defaults={'page': 'index'})
@simple_page.route('/<page>')
def show(page):
    try:
        return render_template('pages/%s.html' % page)
    except TemplateNotFound:
        abort(404)

@simple_page.route 데코레이터와 함수를 연결할 때 블루프린트는 어플리케이션에 있는 그 함수를 등록하겠다는 의도를 기록할 것이다. 게다가 블루프린트는 Blueprint 생성자(위의 경우에는 simple_page) 에 들어가는 그 이름을 가지고 등록된 함수의 끝점 앞에 붙일 것이다.

블루프린트 등록하기¶

그렇다면 블루프린트를 어떻게 등록할 것 인가? 아래와 같이 등록한다:

from flask import Flask
from yourapplication.simple_page import simple_page

app = Flask(__name__)
app.register_blueprint(simple_page)

여러분이 어플리케이션에 등록된 규칙을 확인한다면, 여러분은 아래와 같은 것을 찾을 것이다:

[<Rule '/static/<filename>' (HEAD, OPTIONS, GET) -> static>,
 <Rule '/<page>' (HEAD, OPTIONS, GET) -> simple_page.show>,
 <Rule '/' (HEAD, OPTIONS, GET) -> simple_page.show>]

첫 규칙은 명시적으로 어플리케이션에 있는 정적 파일에 대한 것이다. 다른 두 규칙은 simple_page 블루프린트의 show 함수에 대한 것이다. 볼 수 있는 것 처럼, 블루프린트의 이름이 접두어로 붙어있고 점 (.) 으로 구분되있다.

하지만 블루프린트는 또한 다른 지점으로 마운트 될 수 있도 있다:

app.register_blueprint(simple_page, url_prefix='/pages')

그리고 물론 말할 것도 없이, 아래와 같은 규칙이 생성된다:

[<Rule '/static/<filename>' (HEAD, OPTIONS, GET) -> static>,
 <Rule '/pages/<page>' (HEAD, OPTIONS, GET) -> simple_page.show>,
 <Rule '/pages/' (HEAD, OPTIONS, GET) -> simple_page.show>]

무엇보다 모든 블루프린트이 복수로 적용되는 것에 적절한 응답을 주지는 않지만 여러분은 블루프린트를 여러번 등록할 수 있다. 사실 한번 이상 블루프린트를 마운트할 수 있다면 제대로 블루프린트이 동작하느냐는 블루프린트를 어떻게 구현했으냐에 달려있다.

블루프린트 리소스¶

블루프린트는 리소스 또한 제공할 수 있다. 때때로 여러분은 단지 리소스만을 제공하기 위해 블루프린트를 사용하고 싶을 수도 있다.

>>> simple_page.root_path
'/Users/username/TestProject/yourapplication'

with simple_page.open_resource('static/style.css') as f:
    code = f.read()

admin = Blueprint('admin', __name__, static_folder='static')

url_for('admin.static', filename='style.css')

admin = Blueprint('admin', __name__, template_folder='templates')

URL 만들기¶

하나의 페이지에서 다른 페이지로 링크하고 싶다면 보통 블루프린트명을 접두어로 하고 점 (.) 으로 URL 끝점을 구분하는 것처럼 url_for() 함수를 사용할 수 있다:

url_for('admin.index')

추가적으로 여러분이 블루프린트의 뷰 함수에 있거나 뿌려진 템플릿에 있고 같은 블루프린트의 다른 끝점으로 링크를 걸고 싶다면, 점을 접두어로 하여 끝점에 붙여서 상대적인 리디렉션을 사용할 수 있다:

url_for('.index')

예를 들면 현재 요청을 어떤 다른 블루프린트의 끝점으로 보내는 경우에 admin.index 로 링크할 것이다.

확장기능 찾아내기¶

플라스크 확장기능들의 목록은 Flask Extension Registry 에서 살펴볼 수 있다. 그리고 easy_install 혹은 pip 를 통해 다운로드 할 수 있다. 만약 여러분이 Flask 확장기능을 추가하면, requirements.rst 혹은 setup.py 에 명시된 파일 의존관계로부터 간단한 명령어의 실행이나 응용 프로그램 설치와 함께 설치될 수 있다.

확장기능 사용하기¶

확장기능은 일반적으로 해당 기능을 사용하는 방법을 보여주는 문서를 가지고 있다. 이 확장기능의 작동 방식에 대한 일반적인 규칙은 없지만, 확장기능은 공통된 위치에서 가져오게 된다. 만약 여러분이 Flask-Foo 혹은 Foo-Flask 라는 확장기능을 호출 하였다면, 그것은 항상 flask.ext.foo 을 통해서 가져오게 될 것이다

from flask.ext import foo

Flask 0.8 이전버전의 경우¶

만약 여러분의 Flask가 0.7 버전 혹은 그 이전의 것이라면 flask.ext 패키지가 존재하지 않는다. 대신에 여러분은 flaskext.foo 혹은 flask_foo 등의 형식으로 확장기능이 배포되는 방식에 따라 불러와야만 한다. 만약 여러분이 여전히 Flask 0.7 혹은 이전 이전 버전을 지원하는 어플리케이션을 개발하기 원한다면, 여러분은 여전히 flask.ext 패키지를 불러와야만 한다. 우리는 Flask 의 이전 버전의 Flask를 위한 호환성 모듈을 제공하고 있다. 여러분은 github을 통해서 : flaskext_compat.py 를 다운로드 받을 수 있다.

그리고 여기에서 호환성 모듈의 사용 방법을 볼 수 있다:

import flaskext_compat
flaskext_compat.activate()

from flask.ext import foo

flaskext_compat 모듈이 활성화 되면 flask.ext 가 존재하게 되고 여러분은 이것을 통해 여기서부터 불러오기를 시작 할 수 있다.

요청 컨텍스트 생성하기¶

쉘에서 적절한 요청 컨텍스트를 생성하는 가장 쉬운 방법은 RequestContext: 를 우리에게 생성해주는 test_request_context 메소드를 사용하는 것이다.:

>>> ctx = app.test_request_context()

일반적으로 여러분은 with 구문을 사용하여 이 요청 객체를 활성화 하겠지만, 쉘에서는 push() 와 pop() 를 직접 다루는 방법이 더 쉽다:

>>> ctx.push()

여러분이 pop 을 호출하는 그 시점까지 request 객체를 사용하여 작업 할 수 있다. :

>>> ctx.pop()

요청하기 전/후에 발사하기(Firing)¶

단지 요청 컨텍스트를 생성만 하면, 일반적으로 요청전에 실행되는 코드를 실행할 필요가 없다. 이것은 만약 여러분이 before-request 콜백에서 데이터베이스 연결을 하거나 , 혹은 현재 사용자가 g 객체에 저장하지 않을 경우에 발생할 수 있다..

그러나 이것은 단지 preprocess_request() 를 호출하여 쉽게 수행 할 수 있다:

>>> ctx = app.test_request_context()
>>> ctx.push()
>>> app.preprocess_request()

다음을 염두 해 두어야 한다. 이 경우에 preprocess_request() 함수는 응답(response) 객체를 리턴할 것이고, 이것은 그냥 무시해도 된다.

요청을 종료시키기 위해서, 여러분은 사후 요청 함수 ( process_response() 에 의해 트리거되는)가 응답 객체에서 사용 전에 약간의 트릭을 사용해야 한다:

>>> app.process_response(app.response_class())
<Response 0 bytes [200 OK]>
>>> ctx.pop()

컨텍스트가 열리게 되면 teardown_request() 로 등록된 함수가 자동으로 호출된다. 그래서 이것은 자동으로 요청 컨텍스트 (데이터 베이스 연결과 같은)에 필요한 자원을 해제 할 수 있는 완벽한 장소이다..

쉘 경험을 더욱 향상시키기¶

여러분이 만약 쉘에서의 실험적인 아이디어를 실험하기 좋아한다면, 본인 스스로 여러분의 대화형 세션으로 불러올 모듈을 만들 수 있다. 여기에 또한 여러분은 데이터베이스를 초기화 하거나 테이블을 삭제하는등의 좀 더 유용한 도우미 메소드등을 정의 할 수 있다.

단지 모듈에 이렇게 삽입하면 된다 (shelltools 처럼 불러온다.) :

>>> from shelltools import *