2014-07-21 10 views
6

Przeprowadzamy migrację naszej aplikacji Flask z widoków opartych na funkcjach do widoków w trybie plug-in, wszystko działa zgodnie z oczekiwaniami, z wyjątkiem procedur obsługi błędów. Próbuję umieścić wszystkie moduły obsługi błędów w jednym module o nazwie error_handlers.py i zaimportować je do głównego modułu. Ale to nie działa. Próbowałem wyszukiwania w Google i znaleźć repozytorium Git w ten sam sposób, ale to nie działa dla mnie, pomóż mi rozwiązać ten problem.Czy możemy mieć moduły obsługi błędów Flask w oddzielnym module?

app 
| 
|__ __init__.py 
|__ routing.py (which has the app=Flask(__name__) and imported error handlers here [import error_handlers]) 
|__ views.py 
|__ error_handlers.py (Ex: @app.errorhandler(FormDataException)def form_error(error):return jsonify({'error': error.get_message()}) 
|__ API (api modules) 
     | 
     | 
     |__ __init__.py 
     |__ user.py 

Używam Python 2.6 i Flask 0.10.1.

+0

Czy próbowałeś zaimportować 'error_handlers' do' views'? –

+0

Nie, mam wszystkie moje widoki w module o nazwie views.py, będę teraz edytować strukturę. Próbuję zaimportować to do routing.py, który ma zmienną instancji Flask. –

+0

Cześć Syed, dziękuję, nie mogłem nawet zaimportować error_handlers w widokach. Domyślam się, że to dlatego, że jestem widokami importu w routing.py i ładuję error_handlers w widokach py, które importują aplikację z routing.py .. –

Odpowiedz

0

myślę zaimportować moduł error_handlers w routing.py tak jak

import error_handlers 

lepiej nie importować jak po co w routing.py

from error_handlers import * 

To może być pomóc :-)

+0

Brak syedu, to nie działa. Próbowałem też w ten sposób ... –

+0

Sayed, masz rację, ale jaka jest różnica ?, i działa tylko wtedy, gdy zaimportowałem error_handlers po dodaniu url_rules. –

+0

Po prostu myślę, jeśli zaimportujesz moduł 'error_handlers' jako po prostu' import error_handlers', to zaimportuje moduł error_handler, nie może on użyć kontekstu kolby. Zamiast używać 'from z importu error_handlers *' zaimportuje wszystkie rzeczy w module 'error_handlers', a następnie kontekst aplikacji w kolbie bezpośrednio użyje tych metod. to jest to! –

9

Podczas możesz to zrobić za pomocą jakiegoś circular imports, np .:

app.py

import flask 

app = flask.Flask(__name__) 

import error_handlers 

error_handlers.py

from app import app 

@app.errorhandler(404) 
def handle404(e): 
    return '404 handled' 

Widocznie, to może się trudne w bardziej złożonych scenariuszy.

Flask ma czysty i elastyczny sposób komponowania aplikacji z wielu modułów, koncepcji blueprints. Aby zarejestrować obsługi błędów przy użyciu flask.Blueprint można skorzystać z jednego z nich:

Przykład:

error_handlers.py

import flask 

blueprint = flask.Blueprint('error_handlers', __name__) 

@blueprint.app_errorhandler(404) 
def handle404(e): 
    return '404 handled' 

app.py

import flask 
import error_handlers 

app = flask.Flask(__name__) 
app.register_blueprint(error_handlers.blueprint) 

Oba sposoby osiągnięcia tego samego, zależy od tego, co ci pasuje lepiej.

+0

Nadal nie rozumiem, dlaczego nie powinienem używać @app w error_handlers .. Zamiast używając schematu wybrałem metody Wyświetlenia i widoki, ponieważ nie chcę dodawać więcej wtyczek party 3dr do mojej aplikacji –

+0

@JohnPrawyn Cóż, zależy od tego, co najbardziej Ci odpowiada.Jeśli masz problemy z okrężnymi importami, możesz kontynuować tę drogę. to tylko poręczny sposób na kompozycję aplikacji Dodano również przykład okrężnego importu – famousgarkin

+0

dzięki famousgarkin, w moim przypadku "import e rror_handlers "nie działa, podczas gdy" od importu obsługi error_handlers * działa, to też umieściłem ten wiersz po dodaniu całego app.add_url_rule –

Powiązane problemy