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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 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

                              Only users with full accounts can post comments. Log in, please.