Flask blueprint что это

Blueprints and Views¶

A view function is the code you write to respond to requests to your application. Flask uses patterns to match the incoming request URL to the view that should handle it. The view returns data that Flask turns into an outgoing response. Flask can also go the other direction and generate a URL to a view based on its name and arguments.

Create a Blueprint¶

A Blueprint is a way to organize a group of related views and other code. Rather than registering views and other code directly with an application, they are registered with a blueprint. Then the blueprint is registered with the application when it is available in the factory function.

Flaskr will have two blueprints, one for authentication functions and one for the blog posts functions. The code for each blueprint will go in a separate module. Since the blog needs to know about authentication, you’ll write the authentication one first.

The authentication blueprint will have views to register new users and to log in and log out.

The First View: Register¶

When the user visits the /auth/register URL, the register view will return HTML with a form for them to fill out. When they submit the form, it will validate their input and either show the form again with an error message or create the new user and go to the login page.

For now you will just write the view code. On the next page, you’ll write templates to generate the HTML form.

Here’s what the register view function is doing:

Validate that username and password are not empty.

If validation succeeds, insert the new user data into the database.

For security, passwords should never be stored in the database directly. Instead, generate_password_hash() is used to securely hash the password, and that hash is stored. Since this query modifies data, db.commit() needs to be called afterwards to save the changes.

An sqlite3.IntegrityError will occur if the username already exists, which should be shown to the user as another validation error.

After storing the user, they are redirected to the login page. url_for() generates the URL for the login view based on its name. This is preferable to writing the URL directly as it allows you to change the URL later without changing all code that links to it. redirect() generates a redirect response to the generated URL.

If validation fails, the error is shown to the user. flash() stores messages that can be retrieved when rendering the template.

Login¶

This view follows the same pattern as the register view above.

There are a few differences from the register view:

The user is queried first and stored in a variable for later use.

check_password_hash() hashes the submitted password in the same way as the stored hash and securely compares them. If they match, the password is valid.

session is a dict that stores data across requests. When validation succeeds, the user’s id is stored in a new session. The data is stored in a cookie that is sent to the browser, and the browser then sends it back with subsequent requests. Flask securely signs the data so that it can’t be tampered with.

Logout¶

Require Authentication in Other Views¶

Creating, editing, and deleting blog posts will require a user to be logged in. A decorator can be used to check this for each view it’s applied to.

This decorator returns a new view function that wraps the original view it’s applied to. The new function checks if a user is loaded and redirects to the login page otherwise. If a user is loaded the original view is called and continues normally. You’ll use this decorator when writing the blog views.

Endpoints and URLs¶

The url_for() function generates the URL to a view based on a name and arguments. The name associated with a view is also called the endpoint, and by default it’s the same as the name of the view function.

Источник

Modular Applications with Blueprints¶

Flask uses a concept of blueprints for making application components and supporting common patterns within an application or across applications. Blueprints can greatly simplify how large applications work and provide a central means for Flask extensions to register operations on applications. A Blueprint object works similarly to a Flask application object, but it is not actually an application. Rather it is a blueprint of how to construct or extend an application.

Why Blueprints?¶

Blueprints in Flask are intended for these cases:

Factor an application into a set of blueprints. This is ideal for larger applications; a project could instantiate an application object, initialize several extensions, and register a collection of blueprints.

Register a blueprint on an application at a URL prefix and/or subdomain. Parameters in the URL prefix/subdomain become common view arguments (with defaults) across all view functions in the blueprint.

Register a blueprint multiple times on an application with different URL rules.

Provide template filters, static files, templates, and other utilities through blueprints. A blueprint does not have to implement applications or view functions.

Register a blueprint on an application for any of these cases when initializing a Flask extension.

A blueprint in Flask is not a pluggable app because it is not actually an application – it’s a set of operations which can be registered on an application, even multiple times. Why not have multiple application objects? You can do that (see Application Dispatching ), but your applications will have separate configs and will be managed at the WSGI layer.

Blueprints instead provide separation at the Flask level, share application config, and can change an application object as necessary with being registered. The downside is that you cannot unregister a blueprint once an application was created without having to destroy the whole application object.

The Concept of Blueprints¶

The basic concept of blueprints is that they record operations to execute when registered on an application. Flask associates view functions with blueprints when dispatching requests and generating URLs from one endpoint to another.

My First Blueprint¶

This is what a very basic blueprint looks like. In this case we want to implement a blueprint that does simple rendering of static templates:

When you bind a function with the help of the @simple_page.route decorator, the blueprint will record the intention of registering the function show on the application when it’s later registered. Additionally it will prefix the endpoint of the function with the name of the blueprint which was given to the Blueprint constructor (in this case also simple_page ). The blueprint’s name does not modify the URL, only the endpoint.

Registering Blueprints¶

So how do you register that blueprint? Like this:

If you check the rules registered on the application, you will find these:

Blueprints however can also be mounted at different locations:

And sure enough, these are the generated rules:

On top of that you can register blueprints multiple times though not every blueprint might respond properly to that. In fact it depends on how the blueprint is implemented if it can be mounted more than once.

Nesting Blueprints¶

It is possible to register a blueprint on another blueprint.

The child blueprint will gain the parent’s name as a prefix to its name, and child URLs will be prefixed with the parent’s URL prefix.

Blueprint-specific before request functions, etc. registered with the parent will trigger for the child. If a child does not have an error handler that can handle a given exception, the parent’s will be tried.

Blueprint Resources¶

Blueprints can provide resources as well. Sometimes you might want to introduce a blueprint only for the resources it provides.

Blueprint Resource Folder¶

Like for regular applications, blueprints are considered to be contained in a folder. While multiple blueprints can originate from the same folder, it does not have to be the case and it’s usually not recommended.

To quickly open sources from this folder you can use the open_resource() function:

Static Files¶

A blueprint can expose a folder with static files by providing the path to the folder on the filesystem with the static_folder argument. It is either an absolute path or relative to the blueprint’s location:

Templates¶

If you want the blueprint to expose templates you can do that by providing the template_folder parameter to the Blueprint constructor:

For static files, the path can be absolute or relative to the blueprint resource folder.

The template folder is added to the search path of templates but with a lower priority than the actual application’s template folder. That way you can easily override templates that a blueprint provides in the actual application. This also means that if you don’t want a blueprint template to be accidentally overridden, make sure that no other blueprint or actual application template has the same relative path. When multiple blueprints provide the same relative template path the first blueprint registered takes precedence over the others.

To further reiterate this: if you have a blueprint named admin and you want to render a template called index.html which is specific to this blueprint, the best idea is to lay out your templates like this:

And then when you want to render the template, use admin/index.html as the name to look up the template by. If you encounter problems loading the correct templates enable the EXPLAIN_TEMPLATE_LOADING config variable which will instruct Flask to print out the steps it goes through to locate templates on every render_template call.

Building URLs¶

Additionally if you are in a view function of a blueprint or a rendered template and you want to link to another endpoint of the same blueprint, you can use relative redirects by prefixing the endpoint with a dot only:

This will link to admin.index for instance in case the current request was dispatched to any other admin blueprint endpoint.

Blueprint Error Handlers¶

Blueprints support the errorhandler decorator just like the Flask application object, so it is easy to make Blueprint-specific custom error pages.

Here is an example for a “404 Page Not Found” exception:

Источник

Большой Flask проект

Так получилось, что я сейчас работаю по временному контракту на Google (это не вечно, поэтому даю ссылку на мое резюме).

Оказывается эта большая корпорация не только предоставляет рабочее место с пряничками, вкусно пахнущими смазками для всяких мест через которые вы можно подключиться к благоденствующему миру великой Матрицы и работать на благо победы SkyNet’а. Но и быть обычным гастрабайтером на контракте. Как вы понимаете так даже удобнее, не надо тратить время на утомительные собеседования, переезды в капиталистические страны, сталкиваться с ужасами оформления страховой медицины, подписывания документов и тд.

Моя работа заключается в создании некого инструмента, суть которого интересна не многим. Вы конечно можете его поставить и попробовать, но если вы не занимаетесь подготовкой шрифтов выпускаемых под открытой лицензией OFL и потом их не выкладываете в каталог http://google.com/fonts/, а таких людей ровно 1 во всем мире, то наверное инструмент не станет частью вашего рабочего окружения.

Главное, что исходный код Font Bakery доступен под открытой лицензией Apache 2 и выложен на GitHub. Возможно я переоформлю в отдельный шаблон проекта в будущем, но пока некоторые важные части не представлены в проекте (например миграция и тесты).

Хоть в чем-то мы оказывается совпадаем во вкусах с мегакорпорацией — и я и они верим, что все версии копилефт лицензии GPL это продукт рака мозга маразматика Столлмана и нельзя допускать существования этого отстоя в идеальном мире.

И еще одно отступление.

Есть юридическая тонкость, хоть автором кода и являюсь я, но права и вообще все по контракту я передаю Google, а это значит, что это уже они выкладывают его под APL. Так это работает.

Что внутри

Не имеет смысла углубляться суть проекта, он еще активно пилится. Не стоит его воспринимать как идеальный код, некоторые соглашения не нравятся мне, скорее всего они не покажутся красивыми вам. Главное что если вы столкнетесь с похожей задачей или вам непременно надо будет сделать что-то на Flask, то выкладки и код могут показаться полезными. Первый этап завершен, есть что показать, так что давайте расскажу о технологии. И проведу некоторый code review.

Начну с пересечения сексуальных ключевых слов:

Развертка окружения (Makefile, virtualenv, pip)

Одна из больших проблем, но мною лично очень любимая это развертка окружения проекта. Мне очень не нравятся всякие туториалы о том как надо протянуть левую пятку под правым плечом и нежно постучать себе по жопе для того чтобы поставить какой-то модуль. В идеальном мире проекты должны запускаться двумя командами скачал и запустил. К сожалению, этого достичь не возможно, особенно если у продукта подразумевается более чем одна инсталяция (более чем на одном типе окружения).

Эта проблема вызывает возбуждение не только у меня, поэтому было создано большое множество инструментов, утилит и вообще вокруг этого существует целая индустрия (возможно даже где-то есть секретные братства и ордены).

Сначало надо поставить себе задачу и потом ее решать. Поскольку проект преимущественно python, то прежде всего должно развернуться окружение. В python мире нет единого стандарта развертку окружения, как обычно портят воздух ущербные пользователи Windows у которых нет в стандартной поставке утилиты make. У нас она есть:

Полный файл лежит в репозитории. Если не знаком синтаксис Makefile, то обязательно прочтите руководство, в этом примере видно:

Правильно оформив Makefile можно автоматизировать всю работу по созданию полноценного рабочего окружения и пропадет необходимость бегать по компьютерам сотрудников и устанавливать нужные версии библиотек. Для ruby, javascript (node.js) проектов есть возможность так же разворачивать окружения.

Структура и особенности конфигурирования Flask приложения

Листинг entry.py возьму из другого схожего приложения поскольку в этом есть некоторые особенности о которых будет рассказано ниже, но сейчас они будут мешать пониманию. Для удобства назовем его bigapp:

Если бы подразумевалось, что Font Bakery нужно выкладывать на Heroku, то вместо local.cfg данные бы считывались из переменных окружения, но это не является частью данной статьи. Пока проект никуда не выкладывается.

С моей точки зрения некрасиво получается регистрация глобальных переменных в gvars, но такова архитектура Flask и таких мест пока в масштабах проекта пока мало. Не знаю будет ли их существенно больше на очень крупных проектах:

В строке user = User.query.get(session[‘user_id’]) происходит обращение к базе данных, да при каждом запросе. В совсем крупном проекте надо было бы выделить сервер сессий и класть сессии туда.

Расширения

Каждое расширение сначала просто создает экземпляр, потому что в момент создания расширения не известно какая у него будет конфигурация и не создан экзмепляр Flask приложения. В данном примере github выглядит совсем не красиво, ведь он даже не хранит свои настройки в общей конфигурации. К сожалению на это пришлось пойти чтобы не писать своего wrapper’а вокруг библиотеки rauth.

Чертежи (Flask blueprint)

Наконец-то, чтобы закончить с конфигурацией подошли к модулям, это еще один способ изменить работу Flask’а. Если расширения меняют возможности (можно воспринимать как регистрацияю новых сервисов), то blueprint’ы ближе к добавлению новых подразделов сайта.

Собственно весь код отвечающий за отображаемые страниц находится в blueprint’ах. В текущий момент у проектах их несколько, разделение не совсем удачное, но это то что есть на текущий момент:

Устройство Flask blueprint достаточно простое, оно напоминает обычное Flask приложение за той лишь разницей, что маршрутизация (routing) строится относительно самого bluerprint’а, а не приложения. Для упрощения понимания стоит думать как буд-то бы каждый blueprint может быть подключен к одному и тому же сайту несколько раз (что является правдой).

Весь код выглядит приблизительно так:

Чтобы зарегистрировать все модули используется простой код:

На что обратить внимание

Декоратор login_required позволяет защитить страниц от неавторизированного доступа:

Если пользователь залогинен на GitHub’е и уже дал права Font Bakery, то при попытке зайти на страницу из примера к декторатору /test

Для пользователя это будет выглядеть как секундная задержка перед заходом на закрытую страницу.

Продолжение следует

Если будет достаточный интерес к этому посту и дойдут руки, то в следующем посте я постараюсь подробнее расписать как работает Flask с вебсокетами, socket.io и фоновыми задачами.

Support

If you like my posts, please support me on Gittip

Источник

Модульные приложения Flask с использованием blueprint’ов¶

Добавлено в версии 0.7.

Для чего нужны blueprint’ы?¶

Blueprint’ы во Flask могут пригодиться в случае, если нужно:

Blueprint во Flask не является подключаемым приложением, потому что это на самом деле не приложение – это набор операций, которые могут быть зарегистрированы в приложении, возможно даже не один раз. Почему бы не воспользоваться несколькими объектами приложений? Вы можете это сделать (обратитесь к разделу app-dispatch ), но ваши приложения будут иметь раздельные файлы конфигурации и будут управляться слоем WSGI.

Вместо этого, blueprint’ы предоставляют разделение на уровне Flask, позволяя использовать общий файл конфигурации приложения и могут менять объект приложения необходимым образом при регистрации. Побочным эффектом будет невозможность отменить регистрацию blueprint’а, если приложение уже было создано, если только не уничтожить целиком весь объект приложения.

Концепция blueprint’ов¶

Основная концепция blueprint’ов заключается в том, что они записывают операции для выполнения при регистрации в приложении. Flask связывает функции представлений с blueprint’ами при обработке запросов и генерировании URL’ов от одной конечной точки к другой.

Мой первый blueprint¶

Приведём пример того, как выглядит основа простейшего blueprint’а. В данном случае мы хотим реализовать blueprint, который выполняет простую отрисовку статических шаблонов:

Регистрация blueprint’ов¶

Как теперь зарегистрировать этот blueprint? Например, так:

Если теперь посмотреть на правила, зарегистрированные в приложении, то можно обнаружить следующее:

Однако, blueprint’ы можно связывать с другими местами:

И, чтобы убедиться в этом, посмотрим на правила, сгенерированные на этот раз:

Плюс ко всему, можно зарегистрировать blueprint’ы несколько раз, хотя не каждый blueprint будет работать правильно. Это зависит от того, был ли реализован blueprint’е с учётом возможности многократного монтирования.

Ресурсы blueprint’а¶

Blueprint’ы могут, кроме всего прочего, предоставлять ресурсы. Иногда может потребоваться ввести дополнительный blueprint только ради предоставления ресурсов.

Каталог ресурсов blueprint’а¶

Как и обычные приложения, blueprint’ы задуманы для размещения в отдельном каталоге. Хотя несколько blueprint’ов можно разместить в одном и том же каталоге, так делать не рекомендуется.

Для быстрого открытия ресурсов из этого каталога можно воспользоваться функцией open_resource() :

Статические файлы¶

Шаблоны¶

Если нужно выставить наружу каталог с шаблонами, это можно сделать указав параметр template_folder конструктору Blueprint :

Как и в случае статических файлов, путь может быть абсолютным или располагаться в каталоге ресурсов blueprint’а. Каталог шаблона добавляется к пути поиска шаблонов, но с меньшим приоритетом, чем каталог шаблонов самого приложения. Таким образом, можно легко заменить шаблоны blueprint’а в самом приложении.

Генерирование URL’ов¶

Наконец, если в функции представления blueprint’а или в отрисованном шаблоне нужно добавить ссылку на другую конечную точку того же blueprint’а, можно воспользоваться относительным перенаправлением, добавив префикс, состоящий только из точки:

Получится ссылка на admin.index в случае обработки текущего запроса в любой другой конечной точке blueprint’а.

Обработчики ошибок¶

Вот пример для обработки исключения «404 Page Not Found»:

Источник

#19 Структура и эскиз приложения Flask

У Flask нет никаких ограничений в плане структурирования приложений. Тем не менее существуют советы (гайдлайны) о том, как делать их модульными.

Мы будем использовать следующую структуру приложения.

Ниже описание каждого файла и папки:

Настройки на основе классов

Проект по созданию ПО обычно работает в трех разных средах:

При развитии проекта понадобится определить разные параметры для разных сред. Некоторые также будут оставаться неизменными вне зависимости от среды. Внедрить такую систему конфигурации можно с помощью классов.

Начать стоит с определения настроек по умолчанию в базовом классе и только потом — создавать классы для отдельных сред, которые будут наследовать параметры из базового. Специальные классы могут перезаписывать или дополнять настройки, необходимые для конкретной среды.

Создадим файл config.py внутри папки flask_app и добавим следующий код:

Стоит обратить внимание, что в этом коде значения некоторых настроек впервые берутся у переменных среды. Также здесь есть некоторые значения по умолчанию, если таковые для сред не будут указаны. Этот метод особенно полезен, когда имеется конфиденциальная информацию, и ее не хочется вписывать напрямую в приложение.

Считывать настройки из класса будет метод from_object() :

Создание пакета приложения

После запуска расширений инструкция import на 21 строке импортирует все функции представления. Это нужно, что подключить экземпляр приложение к этим функциям, иначе Flask не будет о них знать.

views.py содержит не только функции представления. Сюда перемещен код моделей, классов форм и другие функции для соответствующих файлов:

Наконец, для запуска приложения нужно добавить следующий код в файл runner.py :

Порядок выполнения

В этом уроке было создано немало файлов, и достаточно легко запутаться в том, за что отвечает каждый из них, а также в порядке, в котором они запускаются. Этот раздел создан для разъяснения всего процесса.

Поскольку runner.py работает как основной модуль, условие на 17 строке выполнено, и manager.run() запускает приложение.

Запуск проекта

Теперь можно запускать проект. В терминале для запуска сервера нужно ввести следующую команду.

Также необходимо проверить остальные страницы приложения, чтобы убедиться, что все работает.

В терминале нужно вести следующую команду для создания переменной среды FLASK_ENV :

Эта команда создает переменную среды в Linux и macOS. Пользователи Windows могут использовать следующую команду:

Снова запустим приложение.

Теперь приложение работает в рабочем режиме. Если сейчас Python вызовет исключения, то вместо трассировки стека отобразится ошибка 500.

Поскольку сейчас все еще этап разработки, переменную среды FLASK_ENV следует удалить. Она будет удалена автоматически при закрытии терминала. Чтобы сделать это вручную, нужно ввести следующую команду:

Пользователи Windows могут использовать следующую команду:

Проект теперь в лучшей форме. Его элементы организованы более логично. Использованный здесь подход подойдет для маленьких и средних по масштабу проектов. Тем не менее у Flask есть еще несколько козырей для тех, кто хочет быть еще продуктивнее.

Blueprints (чертежы/схемы/планы/эскизы)

Эскизы — еще один способ организации приложений. Они предполагают разделение на уровне представления. Как и приложение Flask, эскиз может иметь собственные функции представления, шаблоны и статические файлы. Для них даже можно выбрать собственные URI. Предположим, ведется работа над блогом и административной панелью. Чертеж для блога будет включать функцию представления, шаблоны и статические файлы, необходимые только блогу. В то же время эскиз административной панели будет содержать файлы, которые нужны ему. Их можно использовать в виде модулей или пакетов.

Пришло время добавить эскиз к проекту.

Создание эскиза

Изменить это можно, задав местоположение шаблонов и статических файлов при создании объекта Blueprint :

Вот некоторые вещи, которые важно помнить, когда речь заходит о эскизах:

Этот код вернет URL маршрута index эскиза main.
Можно не указывать название эскиза, если работа ведется в том же эскизе, для которого создается URL. Например:

Стоит обратить внимание, что в файле views.py URL создаются без определения названия эскиза, потому что работа ведется в этом же эскизе.

Также нужно следующим образом обновить вызов url_for() в admin.html :

Сейчас структура приложения выглядит так:

Фабрика приложения

В приложении уже используются пакеты и эскизы (blueprints). Его можно улучшать и дальше, передав функцию создания экземпляров приложения Фабрике приложения. Это всего лишь функция, создающая объект.

Для внедрения фабрики приложения нужно обновить app/__init__.py :

Дальше нужно обновить runner.py для фабрики приложения:

В этих уроках речь шла о многих вещах, которые дают необходимые знания о Flask, его составляющих и том, как они сочетаются между собой.

Источник