Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
Спасибо за статью и труд, симпатично.
Вызывает желание ознакомиться с Flask как таковым. Можете вкратце осветить его основные ± по сравнению с Django?
Вызывает желание ознакомиться с Flask как таковым. Можете вкратце осветить его основные ± по сравнению с Django?
Я бы назвал такие:
1. Меньший размер, мало зависимостей, можно быстро писать приложения в одном .py файле
2. Отдельные компоненты из которых состоит Flask лучше аналогов из Django
3. Explicit is better than implicit, никаких автоимпортов и другой магии кроме threadlocals (которые Django тоже использует)
Из минусов:
1. Надо привыкнуть к чтению документации из кучи разных мест (запросы — Werkzeug, шаблоны — Jinja2, ORM скорее всего SQLAlchemy и так далее).
2. Сторонних компонент явно меньше
3. Начинающим сложнее — слишком много свободы и непонятно что делать
Как-то так.
1. Меньший размер, мало зависимостей, можно быстро писать приложения в одном .py файле
2. Отдельные компоненты из которых состоит Flask лучше аналогов из Django
3. Explicit is better than implicit, никаких автоимпортов и другой магии кроме threadlocals (которые Django тоже использует)
Из минусов:
1. Надо привыкнуть к чтению документации из кучи разных мест (запросы — Werkzeug, шаблоны — Jinja2, ORM скорее всего SQLAlchemy и так далее).
2. Сторонних компонент явно меньше
3. Начинающим сложнее — слишком много свободы и непонятно что делать
Как-то так.
А чем он глобально отличается от того же web.py?
Я когда-то щупал web.py.
У него другая идеология — будем комбайном а-ля Django, что бы все было из коробки. Своя ORM, свои шаблоны и т.д. А в результате, для проектов больше одного файла, все равно используют сторонние библиотеки.
Грубо говоря, это попытка быть Django без ресурсов и community Django. Может оно и не так, но внешне очень похоже.
У него другая идеология — будем комбайном а-ля Django, что бы все было из коробки. Своя ORM, свои шаблоны и т.д. А в результате, для проектов больше одного файла, все равно используют сторонние библиотеки.
Грубо говоря, это попытка быть Django без ресурсов и community Django. Может оно и не так, но внешне очень похоже.
>Отдельные компоненты из которых состоит Flask лучше аналогов из Django
Ээээ, а можете привести примеры?
>… кроме threadlocals (которые Django тоже использует)
Использование threadlocals в джанге считается очень неудачной практикой (причём считается его создателями). Но тут часто действует принцип «если нельзя, но очень хочется...»
Ээээ, а можете привести примеры?
>… кроме threadlocals (которые Django тоже использует)
Использование threadlocals в джанге считается очень неудачной практикой (причём считается его создателями). Но тут часто действует принцип «если нельзя, но очень хочется...»
> Ээээ, а можете привести примеры?
Конечно. Там всего две зависимости: Werkzeug и Jinja2 и очень тонкая прослойка между ними.
Werkzeug умеет много всякого хорошего, например вот такой вот замечательный, интерактивный дебаггер: werkzeug.pocoo.org/docs/debug/
Jinja2, же, очень хороший шаблонизатор с синтаксисом Django. Лучше хотя бы тем, что при ошибках в шаблонах умеет показывать stacktrace и банально работает быстрее.
Если взять третью компоненту — ORM, то это скорее всего будет SQLAlchemy (некоторые еще Peewee используют, я его даже не смотрел). А алхимия сама по себе лучше ORM Django. Можно спорить о удобности и привычности синтаксиса, но как ни крутить — позволяет больше и не заставляет писать сырой SQL в относительно сложных случаях.
Тут скорее дело в том, что Django это комбайн все в одном. Разработчики распыляют свои усилия по достаточно большой кодовой базе. И в каждой своей части, Django работает хоть и не плохо, но хуже чем отдельные специализированные решения. Да, можно сказать что у Django лучше связанность компонент, но на самом деле Flask от слабой связанности не сильно страдает.
Конечно. Там всего две зависимости: Werkzeug и Jinja2 и очень тонкая прослойка между ними.
Werkzeug умеет много всякого хорошего, например вот такой вот замечательный, интерактивный дебаггер: werkzeug.pocoo.org/docs/debug/
Jinja2, же, очень хороший шаблонизатор с синтаксисом Django. Лучше хотя бы тем, что при ошибках в шаблонах умеет показывать stacktrace и банально работает быстрее.
Если взять третью компоненту — ORM, то это скорее всего будет SQLAlchemy (некоторые еще Peewee используют, я его даже не смотрел). А алхимия сама по себе лучше ORM Django. Можно спорить о удобности и привычности синтаксиса, но как ни крутить — позволяет больше и не заставляет писать сырой SQL в относительно сложных случаях.
Тут скорее дело в том, что Django это комбайн все в одном. Разработчики распыляют свои усилия по достаточно большой кодовой базе. И в каждой своей части, Django работает хоть и не плохо, но хуже чем отдельные специализированные решения. Да, можно сказать что у Django лучше связанность компонент, но на самом деле Flask от слабой связанности не сильно страдает.
peewee кстати может и зря порпускаем — мельком смотрел, вроде неплохо. Хотя вот админка приколоченная к орму, эту болезнь уже вроде проходили.
Дебаггер из werkzeug легко и к джанге правда приколачивается. runplus, или как там, давно не писал под. А вот джинджу с большими трудами, и стандартные компоненты все равно рисуют через джангу, и в общем возможны неудобства.
У Flask мне кажется не просто компоненты — сам принцип построения удачнее.
У Flask мне кажется не просто компоненты — сам принцип построения удачнее.
threadlocals не очень верно. На самом деле, при нырянии в код джанги и werkzeug, становится понятно, что flask под gevent можно запускать смело, django лучше не стоит — werkzeug учитывает гринлеты, и делает для них специальные обертки.
Рыбу фугу тоже жрать опасно, но если руки у повара прямые, то можно.
Ну в качестве примера можно привести sqlalchemy, хоть она и не компонент именно фласка. Jinja2 — ну тоже как бы отдельно можно использовать, но в общем джанговские темплейты она обходит и по скорости и по фичастости/гибкости.
Flask-Admin вот еще например — заложенная гибкость действительно на хорошем уровне. Ну и в общем все что под фласк написано, оно несколько с другой философией идет, более питоник, более модульное.
После знакомства с фласком у меня получается писать с минимумом магии, и при этом весьма и весьма прикладисто.
Рыбу фугу тоже жрать опасно, но если руки у повара прямые, то можно.
Ну в качестве примера можно привести sqlalchemy, хоть она и не компонент именно фласка. Jinja2 — ну тоже как бы отдельно можно использовать, но в общем джанговские темплейты она обходит и по скорости и по фичастости/гибкости.
Flask-Admin вот еще например — заложенная гибкость действительно на хорошем уровне. Ну и в общем все что под фласк написано, оно несколько с другой философией идет, более питоник, более модульное.
После знакомства с фласком у меня получается писать с минимумом магии, и при этом весьма и весьма прикладисто.
Пользуюсь этой штукой еще в бытность ее админкой в svarga. С переносом по flask стала еще лучше.
То есть моя личная рекомендация очень пристально смотреть и проникнуться.
То есть моя личная рекомендация очень пристально смотреть и проникнуться.
Кстати, что со Сваргой — померла, как и большинство микрофреймворков на WZ с появлением Flask?
Ага, была заморожена.
Сварга, идеологически, была очень похожа на Flask. Ну или наоборот, Flask появился на пол года позже. Те же идеи с threadlocals, та же основа — Werkzeug, Jinja2. Разница только в том, что у Сварги было много идей позаимствовано из Django и идеи эти были не самыми лучшими. Например — структура приложений, автоимпорт моделей и т.д.
Когда анонсировали Flask, стало сразу понятно что его будет использовать больше народа чисто за счет большего community pocoo. И было принято решение заморозить Сваргу и потихоньку перетаскивать наработки во Flask. Что, собственно, и происходит.
Сварга, идеологически, была очень похожа на Flask. Ну или наоборот, Flask появился на пол года позже. Те же идеи с threadlocals, та же основа — Werkzeug, Jinja2. Разница только в том, что у Сварги было много идей позаимствовано из Django и идеи эти были не самыми лучшими. Например — структура приложений, автоимпорт моделей и т.д.
Когда анонсировали Flask, стало сразу понятно что его будет использовать больше народа чисто за счет большего community pocoo. И было принято решение заморозить Сваргу и потихоньку перетаскивать наработки во Flask. Что, собственно, и происходит.
Спасибо, люблю Фласк и давно пользуюсь вашей админкой!
Огромное спасибо за Ваш труд. Месяц назад начал использовать flask-admin и был приятно удивлен гибкостью. Я думаю, что bootstrap здесь очень к месту. В целом нравится намного больше, чем админка в django.
вобще приятно что наконец начали появлятся такие штуки.
а то даже я от лени предпочитаю джангу — лижбы с админкой не парится
а то даже я от лени предпочитаю джангу — лижбы с админкой не парится
Пользуемся вашей админкой. Допиливал только не очень гибкий is_accessible.
Большое вам спасибо :)
Большое вам спасибо :)
А что там не работало?
В моем случае надо было при ошибке доступа редиректить на форму логина и сохранять пут для возврата, а не возвращать ошибку. Возможно это не редкая ситуация
Но это просто решилось переопределением метода handle_view + к is_accessible
def _handle_view(self, name, **kwargs):
if not self.is_accessible():
#Some Actions
А, понял что имеется в виду.
Да, можно сделать так:
А можно кинуть RequestRedirect(url) из самого is_accessible и произойдет редирект.
Да, можно сделать так:
def _handle_view(self, name, **kwargs):
if not self.is_accessible():
return login.current_app.login_manager.unauthorized()
А можно кинуть RequestRedirect(url) из самого is_accessible и произойдет редирект.
Спасибо вам за вашу работу!
Приладил к Pylons через middleware.
Спасибо, очень симпатично и удобно.
Спасибо, очень симпатично и удобно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Flask-Admin