Ich versuche, mit Blueprints eine "modulare Anwendung" in Flask zu erstellen.

Beim Erstellen von Modellen stoße ich jedoch auf das Problem, auf die App verweisen zu müssen, um die zu erhaltendb-Objekt bereitgestellt von Flask-SQLAlchemy. Ich möchte in der Lage sein, einige Blaupausen mit mehr als einer App zu verwenden (ähnlich wie Django-Apps verwendet werden können), daher ist dies keine gute Lösung. *

Es ist möglich, ein Switcharoo durchzuführen und den Blueprint das erstellen zu lassendb Instanz, die die App dann zusammen mit dem Rest der Blaupause importiert. Aber dann muss jeder andere Entwurf, aus dem Modelle erstellt werden sollen, importiert werdenDas Blaupause anstelle der App.

Meine Fragen sind also:

Gibt es eine Möglichkeit, Blueprints Modelle definieren zu lassen, ohne die App zu kennen, in der sie später verwendet werden - und mehrere Blueprints zusammenzuführen? Damit meine ich, dass Sie das App-Modul / -Paket von Ihrem Blueprint importieren müssen.Irre ich mich von anfang an Sollen Blueprints nicht unabhängig von der App und weiterverteilbar sein (à la Django-Apps)?Wenn nicht, welches Muster?sollte benutzt du um so etwas zu kreieren? Kolbenverlängerungen? Sollten Sie es einfach nicht tun - und vielleicht alle Modelle / Schemata à la Ruby on Rails zentralisieren?

Bearbeiten: Ich habe jetzt selbst darüber nachgedacht, und dies könnte mehr mit SQLAlchemy zu tun haben als mit Flask, weil Sie das haben müssendeclarative_base() bei der Angabe von Modellen. Unddas ist es muss sowieso irgendwo herkommen!

Vielleicht ist es die beste Lösung, das Schema Ihres Projekts an einem Ort zu definieren und zu verteilen, wie es Ruby on Rails tut. Deklarative SQLAlchemy-Klassendefinitionen ähneln eher schema.rb als Djangos models.py. Ich stelle mir vor, dies würde es auch einfacher machen, Migrationen zu verwenden (vonAlembic odersqlalchemy-migrate).

Ich wurde gebeten, ein Beispiel anzugeben, also lassen Sie uns etwas Einfaches tun: Angenommen, ich habe eine Blaupause, die "Flatpages" beschreibt - einfache, "statische" Inhalte, die in der Datenbank gespeichert sind. Es wird eine Tabelle mit nur einem Kurznamen (für URLs), einem Titel und einem Text verwendet. Das istsimple_pages/__init__.py:

from flask import Blueprint, render_template
from .models import Page

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

@flat_pages.route('/<page>')
def show(page):
    page_object = Page.query.filter_by(name=page).first()
    return render_template('pages/{}.html'.format(page), page=page_object)

Dann wäre es schön, diesen Entwurf sein eigenes Modell definieren zu lassen (dies insimple_page/models.py):

# TODO Somehow get ahold of a `db` instance without referencing the app
# I might get used in!

class Page(db.Model):
    name = db.Column(db.String(255), primary_key=True)
    title = db.Column(db.String(255))
    content = db.Column(db.String(255))

    def __init__(self, name, title, content):
        self.name = name
        self.title = title
        self.content = content

Diese Frage bezieht sich auf:

Flask-SQLAlchemy-Import- / KontextproblemWie sieht Ihr Ordnerlayout für eine Flask-App aus, die in Module unterteilt ist?

Und verschiedene andere, aber alle Antworten scheinen darauf zu beruhen, die App's zu importierendb Beispiel oder umgekehrt. Das"Große App, wie es geht" Die Wiki-Seite verwendet auch das Muster "Importiere deine App in deinen Bauplan".

* Da die offizielle Dokumentation zeigt, wie Routen, Ansichten, Vorlagen und Elemente in einem Blueprint erstellt werden, ohne sich darum zu kümmern, in welcher App sie sich befinden, bin ich davon ausgegangen, dass Blueprints im Allgemeinen für alle Apps wiederverwendbar sein sollten. Diese Modularität scheint jedoch nichtDas nützlich, ohne auch unabhängige Modelle zu haben.

Da Blueprints mehr als einmal in eine App eingebunden werden können, ist es möglicherweise falsch, Modelle in Blueprints zu haben.