routage

@app.route("/itcast")
def view_func():
    return "hello world"

1 Requête des informations de routage

Ligne de commande

flask routes

Endpoint  Methods  Rule
--------  -------  -----------------------
index     GET      /
static    GET      /static/

Insérez la description de l'image ici
Flask fournira le routage pour accéder aux fichiers statiques par défaut

Participez au programme

Les informations de mappage de routage de l'ensemble de l'application Flask sont stockées dans l'attribut url_map de l'application, et les informations de routage peuvent être obtenues en lisant cet attribut

print(app.url_map)

Insérez la description de l'image ici

Si vous souhaitez parcourir les informations de routage dans le programme, vous pouvez utiliser la méthode suivante

for rule in app.url_map.iter_rules():
    print('name={} path={}'.format(rule.endpoint, rule.rule))

demande

Renvoie toutes les informations de routage dans l'application au format json via accès / adresse

atteindre

@app.route('/')
def route_map():
    """
    主视图，返回所有视图网址
    """
    rules_iterator = app.url_map.iter_rules()
    return json.dumps({
    
    rule.endpoint: rule.rule for rule in rules_iterator})

Insérez la description de l'image ici

2 Spécifiez la méthode de demande

Dans Flask, la méthode de demande par défaut pour le routage est définie comme suit :

AVOIR
OPTIONS (incluses) -> Requête Get simplifiée, l'utilisateur demande des informations sur l'interface du serveur
HEAD (inclus) -> demande Get simplifiée, seul l'en-tête de réponse traité par la demande get est retourné, pas le corps de la réponse

Pour la même requête, l'utilisation de get renverra toutes les informations, en utilisant head, ne contient que le code d'état et les en-têtes de réponse

Utilisez des methodsparamètres pour spécifier vous-même la méthode de demande d'une interface

L'attribut methods modifiera la méthode de requête de l'itinéraire de manière prioritaire. La première route ci-dessous ne prendra en charge que la publication, et la deuxième route ne prendra en charge que la récupération et la publication.

@app.route("/itcast1", methods=["POST"])
def view_func_1():
    return "hello world 1"

@app.route("/itcast2", methods=["GET", "POST"])
def view_func_2():
    return "hello world 2"

plan

demande

Dans un projet d'application Flask, s'il y a trop de vues d'entreprise, les unités commerciales divisées d'une certaine manière peuvent-elles être gérées séparément, et les vues, les fichiers statiques et les fichiers modèles utilisés par chaque unité peuvent être séparés indépendamment?

Par exemple, d'un point de vue métier, toute l'application peut être divisée en unités de module utilisateur, en unités de module de produits et en unités de module de commande. Comment développer ces différentes unités séparément et enfin les intégrer dans une application de projet?

Comment cette exigence est-elle satisfaite dans Django?

plan

Django est appelé un plan et flask est appelé une sous-application. Le
plan doit inclure autant que possible les ressources utilisées par cette sous-application.
Dans Flask, le plan est utilisé pour organiser et gérer les modules.

Un plan directeur peut en fait être considéré comme un objet conteneur qui stocke un ensemble de méthodes d'affichage. Il présente les caractéristiques suivantes:

Une application peut avoir plusieurs Blueprints
Vous pouvez enregistrer un Blueprint sur n'importe quelle URL inutilisée telle que "/ user", "/ goods"
Blueprint peut avoir ses propres modèles, fichiers statiques ou autres méthodes générales de fonctionnement uniquement, il n'est pas nécessaire d'implémenter les vues et les fonctions de l'application
Lorsqu'une application est initialisée, elle doit enregistrer le Blueprint
** mais un Blueprint n'est pas une application complète, il ne peut pas s'exécuter indépendamment de l'application, mais doit être enregistré dans une certaine application. ** Comme Django, il ne peut pas être exécuté indépendamment, il doit être enregistré dans un certain projet

Comment utiliser

L'utilisation de plans peut être divisée en trois étapes

Pour créer un objet blueprint, le
premier paramètre est le nom du blueprint et
__name__ est utilisé pour déterminer l'emplacement du blueprint

 user_bp=Blueprint('user',__name__)

Opérez sur cet objet de plan directeur, enregistrez des itinéraires, spécifiez des dossiers statiques et enregistrez des filtres de modèle

 @user_bp.route('/')
 def user_profile():
     return 'user_profile'

Enregistrer l'objet de plan directeur sur l'objet d'application

 app.register_blueprint(user_bp)

Insérez la description de l'image ici

url_prefix est utilisé pour ajouter un préfixe lorsque cette route correspond

Plan directeur de fichier unique

Vous pouvez créer des objets de plan directeur et définir des vues dans un seul fichier.

Plan de catalogue (package)

Les vues peuvent être placées dans un seul fichier ou dans plusieurs fichiers

Pour un blueprint qui a l'intention de contenir plusieurs fichiers, la création de l'objet blueprint est généralement placée dans le __init__.pyfichier du package Python

--------- project # 工程目录
  |------ main.py # 启动文件
  |------ user  #用户蓝图
  |  |--- __init__.py  # 此处创建蓝图对象
  |  |--- passport.py  
  |  |--- profile.py
  |  |--- ...
  |
  |------ goods # 商品蓝图
  |  |--- __init__.py
  |  |--- ...
  |...

Insérez la description de l'image ici

Enregistrez le plan.

Faites attention d'ajouter la phrase suivante, chargez le contenu des vues.

Cette phrase doit être placée à la fin, sinon elle entraînera des références circulaires.

Utilisation étendue

1 Spécifiez le préfixe URL du plan

Utilisez des url_prefixparamètres à spécifier lors de l'enregistrement des plans dans l'application

app.register_blueprint(user_bp, url_prefix='/user')
app.register_blueprint(goods_bp, url_prefix='/goods')

2 fichiers statiques à l'intérieur du plan

Contrairement à l'objet d'application, l'itinéraire du répertoire statique n'est pas enregistré par défaut lors de la création de l'objet de plan directeur. Nous devons spécifier le paramètre static_folder lors de sa création .

L'exemple suivant définit le répertoire static_admin dans le répertoire où se trouve le plan directeur en tant que répertoire statique

admin = Blueprint("admin",__name__,static_folder='static_admin')
app.register_blueprint(admin,url_prefix='/admin')

Vous pouvez maintenant utiliser les fichiers statiques dans le répertoire d' /admin/static_admin/<filename>accès static_admin.

Vous pouvez également static_url_pathmodifier le chemin d'accès

admin = Blueprint("admin",__name__,static_folder='static_admin',static_url_path='/lib')
app.register_blueprint(admin,url_prefix='/admin')

3 Catalogue de modèles internes Blueprint

Le répertoire de modèle par défaut de l'objet de plan directeur est le répertoire de modèle système. Vous pouvez utiliser le paramètre de mot clé template_folder pour définir le répertoire de modèle lors de la création de l'objet de plan directeur.

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

Remarques

Cet accès dans Django obtiendra toutes les informations de routage
for i in
iterable object La position de l'objet iterable est obtenue par calcul Il est bon de savoir quel objet traverser dans votre esprit.
Comment résoudre le problème de l'accès interdomaine ? Django-cors fournit une requête pour les options de traitement. Dans le middleware, les options de requête d'

options n'impliquent pas de logique métier. Il ne demande que des informations d'interface. La source de la requête doit être autorisée

n'a besoin que de la solution cors pour le traitement. Les idées sont les mêmes
Le but de la création d'applications dans Django est de les réutiliser. De cette façon, chaque application peut être séparée de Django. Par exemple, le module utilisateur peut être directement utilisé par d'autres sites Web, et l' application peut être réutilisée et étendue.
Faites attention aux trois étapes du plan directeur: 1. Créez le plan directeur 2. Enregistrez l'itinéraire du plan directeur 3. Enregistrez le plan directeur
10. Selon pep8, guidez l'emballage et installez le module de guidage autant que possible
DEBUG dans Django prend en charge les fichiers statiques. Les erreurs dans le backend seront affichées directement sur la page frontale. Après la modification du code, le serveur de développement sera automatiquement redémarré. Le débogage de Flask ne prend pas en charge les fichiers statiques, mais prend en charge les deux derniers à

exécuter en mode débogage. En mode débogage, l'erreur du serveur n'affichera pas les informations détaillées sur l'erreur