Легкий 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 обладает довольно хорошей документацией, так что заходите и читайте. Хороших всем выходных!
    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 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'ом — это позволяет выжать гораздо больше запросов в секунду даже на относительно слабых машинах.
                    • –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

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