Pull to refresh

Comments 31

Спасибо за обзор. Очень напоминает php фреймворк Silex.
Пробовал его, даже пытались что-то разрабатывать.

Он удобен только для вещей вроде «я и моя хомепага». Основная идея автора — весь фреймворк в одном .py-файле, без установки каких-либо зависимостей (что в каких-то ситуациях именно то, что нужно). Кинул 3 файла (фреймовк, аппу и sqlite-базу) на сервер — и всё завелось. Самое то для лёгких серверов, где бекенд — не основная часть и нужно быстро стартануть что-то очень простое. Просто и со вкусом.

Но для чего-то более серьёзного и масштабного, что ещё и разрастается со временем он по всем параметрам сливает Flask'у, на котором, в итоге, и делаем проекты.

Согласен… Хотя в принципе можно переделать ботлу, что я и сделал. Только ИМХО в итоге фляга/джанга и вышла :).
Скорость разработки небольших проектов. Если ничего громадного не требуется — набросал по-быстрому и поставил.
А что во Flask не так с «набросал по-быстрому и поставил»?
Ну впринципе они довольно похожи, но в любом случае bottle проще и что-то сделать на нем займет меньше времени
«в любом случае» — замечательный аргумент.
Факт того, что bottle проще довольно очевиден, его как бы для этого и задумывали. Я же не говорю, что простота всегда лучше, просто для маленьких проектов код на bottle писать проще, чем на flask'e
Хелоуворлд на Фласке не длиннее, чем на Ботле. Аргумент предложил JC_Piligrim — можно кинуть bottle.py рядом со скриптом приложения и не возиться с установкой пакетов, виртуальными средами, если нет прав и т. д.
У Bottle недавно было сильное преимущество — поддержка Py3, но сейчас Flask тоже умеет.
Bottle быстрее по «hello world пузомерке», +фреймворк в одном файле, + есть готовые адаптеры к разным шаблонизаторам и серверам.
Flask может быть интересен какими-то плагинами, вроде их кол-во больше чем у Bottle.
Если любите копаться в коде фреймворков, Bottle — простой, меньше кода.

Вообщем сейчас особой разницы нет, лично я предпочитаю Bottle, т.к. его для многого хватает — использую его более 4 лет и переходить на Flask смысла нет.
Познакомился с Bottle, когда проходил курсы по MongoDB. Милый, простой, понятный.
Но, честно говоря, не вижу смысла в «ein framework ein file». Потому как для любого мало-мальски серьёзного проекта кроме фрэймворка придётся использовать целую гору других файлов.
Та же ситуация со знакомство. Написал небольшой сайт на нем, полтора года без проблем работает
Очень похоже на очередной клон Sinatra.
Одна из сильнейших сторон фреймворка — механизм шаблонов.


Не щупал другие шаблонизаторы, но по ощущениям шаблонизатор bottle чересчур минималистичен. Я бы не сказал, что это сильная сторона bottle.

Чтобы воспользоваться шаблонизатором, достаточно написать такую легкую конструкцию:
template('template_name', name=name, number=number, foo=bar)


По моему гораздо красивше использовать декоратор @view("template_name") и вернуть из функции dict с подстановками.

Следует отметить, что bottle.py дружит с gevent'ом — это позволяет выжать гораздо больше запросов в секунду даже на относительно слабых машинах.
Также Bottle предоставляет нам очень очень крутую возможность: писать любой python код внутри шаблона. Чтобы вызвать питон, достаточно в начале строки поставить %. Например:
%a = 100500
%for i in xrange(a):
    <div class="image_{{i}}"><img src="......{{i}}.jpg"></div>
%end 


А что написать цикл на шаблонизаторе Bottle без использования кода на python нельзя?
Какой-то странный у вас вопрос. А на чем вы хотели цикл написать?
Может быть, на специальных шаблонных тегах?
Зачем вводить специальные теги (т.е. ещё один язык), если и так есть питон и его можно применить? Во Flask (Jinja) так сделано — со специальными тегами — не сказал бы что удобнее на вид.
Да, конечно, давайте создадим свой новый синтаксис непонятно зачем. Чем питон не устраивает? Это ведь очень простой случай, а бывает, что у нас есть огромный словарь, в котором еще есть куча списков и.т.д. Так зачем выдумывать что-то новое, когда питон является одним из самых удобных языков для таких целей?
Я всего лишь предположил, что имел ввиду maleficxp. Я не специалист в движках шаблонов, но раз и в Джанге, и Флаксе для циклов, условий и т. д. все специальные теги, видимо, на это есть причины.
В Django так сделано по крайней мере по двум причинам:

  1. Разграничение доступа — в ряде случаев доступ к редактированию шаблонов есть у относительно широкого круга лиц. Соответственно, необходимо, чтобы управлять отображением чего-либо на сайте эти люди могли, но вот выполнять произвольный Python-код — нет. При этом с Django поставляется, например, тэг ssi (чтение любого файла в шаблоне), но чтобы использовать его с каким-либо файлом, одна из родительских директорий должна быть указана в настройке ALLOWED_INCLUDE_ROOTS. То есть, как видите, по умолчанию всё сделано так, чтобы из шаблонов можно было делать только то, что необходимо в шаблонах, а не что угодно.
  2. Предполагается, что есть бэкэнд-разработчики, а есть фронтэнд-разработчики. Соответственно, фронтэнд-разработчики, которые не знают Python, таким образом получают возможность самостоятельно писать шаблоны.
По второму пункту непонятно, чем лучше какой-то отдельный язык для программирования действий в шаблонах по сравнению с питоном. Если фронтэнд разработчик не знает питон, то уж этот специальный язык он скорее всего тем более не знает.
Вы правда уверены, что все дизайнеры, верстающие сайты, владеют языками программирования, на которых написаны используемые ими шаблонизаторы?
Да, именно это я и имел в виду. Согласно идеологии MVC логика живет отдельно от представления. То есть логику пишет программист на языке программирования, а шаблоны верстает дизайнер на языке шаблонов.
Лично я много работаю со Smarty (php), там, конечно, тоже можно вставить код php в шаблон, но даже в документации написано, что так делать не рекомендуется.
Вот же дураки, напридумывали непонятных тэгов, когда все нормальные пацаны прямо на python-е пишут
Виноват, конечно, надо было сразу понять, что раз фреймворк микро-, то дизайнер и программист это одно лицо, и не задавать глупых вопросов.
Ну это с Django Bottle играет явно в разных весовых категориях. Не могу даже представить себе варианта работы большой команды с проектом на Bottle. Тут же типовой usecase — поднять на скорую руку веб мордочку или слепить сайт на несколько страниц. С таким использованием его применяют в основном админы и backend программисты для служебных целей, а не команда верстальщиков.

И если это так — то зачем что-то усложнять дополнительными шаблонными тегами?
Не могу даже представить себе варианта работы большой команды с проектом на Bottle.

Почему нет? В Bottle есть все необходимое, на нем можно сделать свою архитектуру, свой фреймворк (свою «джангу») и т.п.
Как раз для больших проектов иногда удобнее сделать свою архитектуру, чем использовать чужую (навязанную фреймворком).
А вот про Django ходят слухи, что в больших приложении в конечном счете 95% функционала джанги (в основном плагинов) переписывается, т.е. же штатные комментарии сразу рекомендуют «выкинуть».

Поэтому такие как Bottle, Flask, Pyramid (по гибкости) тоже могут рассматриваться на роль в больших проектах.
Понятно, что все можно переписать =) Про 95% переписываемого функционала Django — немного погорячились. Плагины плагинами, но ORM, генератор админки, синхронизация БД, шаблонизатор, консольные команды и пр. А в 1.6 — еще и неплохие миграции из коробки — это то что особо не переписывают. Только админку всячески декорируют.

Я много всяких чудес насмотрелся за свою жизнь, но сильно сомневаюсь в адекватности архитектора, который для крупного бизнес-проекта в большой команде выберет микрофреймворк. Пусть даже как базу для последующего изменения. Imho
Sign up to leave a comment.

Articles