Пользователь
0,0
рейтинг
3 мая 2014 в 01:51

Разработка → Легкий python веб-фреймворк: Bottle

Введение


Недавно я осознал, что на Хабре нет ни одной статьи, посвящённой прекрасному фреймворку Bottle, которым, кстати говоря, пользуется не мало людей, поэтому в этой статье я попытаюсь рассказать вам о нем.

Установка


Bottle — очень легкий фреймворк и помещается всего в один файл — bottle.py. Установить его можно отсюда, либо сделать pip install bottle.

Возможности


Несмотря на свою минималистичность, Bottle предоставляет довольно широкие возможности, которых на 100% хватает для мелких и средних проектов. Вот список основных возможностей:

Routing

Роутинг в bottle, как и в большинстве фреймворков на питоне, осуществляется с помощью декораторов. Например:
@route('/hello/<name>')
def index(name):
    return name

Также динамические url можно составлять на основе регулярных выражений:
@route('/news/<number:re:[0-9]*>')
def show_news(number):
    pass

Templates

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

Первый аргумент функции — название файла, в котором содержится текст шаблона (в нашем случае шаблон будет называться template_name.tpl).
В самом же файле нам нужно написать название переменной в двух фигурных скобках:
Hello, {{name}}, glad to see you!

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

Также можно инклюдить шаблоны из шаблонов, что позволяет нам красиво и опрятно содержать шаблоны.
%include template_num2 foo=bar, blabla=qweqwe

POST-routing и обработка форм

Какой же нормальный фреймворк может существовать без возможности обработки POST запросов с последующей обработкой форм?
Механизм для обработки POST запросов абсолютно такой же, как и для обработки GET запросов, просто слово route нужно заменить на post:
@post("/url")
def foo():
    pass

Для доступа к формам используются атрибуты полей «name». Например:
<input name="age" placeholder="Возраст">

Чтобы получить содержимое формы, нужно использовать следующую конструкцию:
request.forms.get("age")  # Получить содержимое одного поля age
request.forms.getall("age")  # Получить содержимое всех полей age

Также можно обращаться и с файлами:
request.files.get("picture")  # Получить один файл из поля picture
request.files.getall("picture")  # Получить все файлы из поля (mult-upload)

Cookies

Обращаться с Cookies в bottle очень просто, чтобы установить cookie:
response.set_cookie("name", value, max_age=100500)

Чтобы взять значение:
request.get_cookie("name")

Сервер

В bottle вшит простой http сервер, который пригоден разве что для очень быстрого тестирования одной странички:
run(host='localhost', port=8080)

Естественно, что для более крупных проектов использовать его невозможно, поэтому надо как-то связать bottle с apache или nginx. Честно говоря, сам я всегда использую apache, поэтому рассказать могу только про него, но с ngninx все тоже вроде довольно просто. Bottle связывается с Apache через mod_wsgi. Для того, чтобы это реализовать, нужно сделать следующее:
  1. Создать файл adapter.wsgi с вот таким содержимым
    спойлер
    import sys, os, bottle
    sys.path.append(os.path.dirname(os.path.abspath(__file__)))
    os.chdir(os.path.dirname(os.path.abspath(__file__)))
    import index # Основной файл
    
    application = bottle.default_app()
    

  2. Установить и включить mod_wsgi
  3. Добавить настройки виртуального хоста
    спойлер
    <VirtualHost *:80>
            DocumentRoot /var/www/foo
    </VirtualHost>
    
    <Directory /var/www/foo>
            Options FollowSymLinks ExecCGI
            AddHandler wsgi-script .wsgi
            Order allow,deny
            AllowOverride All
            Allow from all
    </Directory>
    



Частые ошибки и их решения


  • Если ваш сайт работает через apache, то нужно быть очень аккуратным в работе с путями, нужно всегда использовать полные пути. Мой вам совет: где-нибудь в начале кода правильно определите рабочий каталог, а дальше просто везде его используйте. Например, вот так:
    sys.path.append(os.path.dirname(os.path.abspath(__file__)))
    os.chdir(os.path.dirname(os.path.abspath(__file__)))
    cwd = os.getcwd()
    

  • Если вы берете шаблоны из какой-то папки (например views), то обязательно нужно добавить полный путь до этой папки в список bottle.TEMPLATE_PATH

Заключение


Естественно, сложно в один пост уместить всю информацию о фреймворке, я написал лишь самое главное. Благо bottle обладает довольно хорошей документацией, так что заходите и читайте. Хороших всем выходных!
Степан Нерсисян @SteveNers
карма
6,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (31)

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.