Puli: Управление ресурсами в php приложениях +8



imagePuli — это инструмент, позволяющий универсально управлять ресурсами в php приложениях. Главная цель проекта — стандартизировать такие понятия как bundle, plugin, module для разных библиотек и фраймворков в одно общее независимое решение.

В чем проблема?

Иногда, вы возможно получали файл, используя константу __DIR__:

echo file_get_contents(__DIR__.'/../../res/views/index.html.twig');

Однако, как правило при доработке проекта путь к файлу меняется, и данный код перестает работать. Но многие фраймворки используют собственное решение с предустановленной root директорией, где лежать ваши ресурсы.

// res/views/index.html.twig
echo load_file('views/index/html.twig');

Такое решение работает неплохо. А что если вы хотите загрузить ресурсы из другой директории, допустим из установленной через composer библиотеки. Фреймворки решают эту проблему, поддерживая aliases для ресурсов.

// vendor/acme/blog/res/views/index.html.twig
echo load_file('acme-blog:views/index/html.twig');

К сожалению, каждый фреймворк имеет собственные соглашения о наименовании директорий.

Как работает Puli

Компонент для управления ресурсами через репозитории принимает путь, как в файловой системе Unix.

// res/views/index.html.twig
echo $repo->get('/app/views/index.html.twig')->getBody();

Puli находит файлы с помощью puli.json в корне вашего проекта и во всех установленных композером пакетах. Добавить новый путь можно с помощь команды:

$ php puli.phar map /app res

В данном примере мы добавили приставку /app для res директории вашего приложения. Сейчас Puli знает, что все файлы с приставкой /app должны быть найдены в директории res.

image

Puli собирает данные о путях из puli.json вашего проекта.

URL генератор

Когда вы пишите html, css, javasript код, вы часто нуждаетесь в других ресурсах. Для примера ссылка на картинку в html теге img:

<img src="/images/logo.png" />

Возможно, всё будет работать, но если вы заходите хранить ваши изображения на другом сервере? Если ваш код является частью composer пакета, вы заставляете пользователей публиковать ваши ресурсы с точностью, как в вашем html файле.

Puli решает эту проблему автоматической генерацией URL.

<img src="{{ resource_url("/batman/blog/public/images/logo.png") }}" />

Относительный путь:

<img src="{{ resource_url("../public/images/logo.png") }}" />

Пользователи вашего пакета нуждаются в небольшой настройке Puli.

image

Теперь пользователь должен указать как минимум один web сервер (название и URL формат). Для примера используем localhost как имя и examle.com/%s как URL формат для нашего web сервера. Мы настроили наш puli так, что путь /batman/blog/public соответствовал корневой директории /blog/ нашего web сервера. Получаем URL:

<img src="https://example.com/blog/images/logo.png" />

Puli может автоматически разместить ваши ресурс для web сервера. Указав ваш web сервер и как ваши ресурсы должны быть опубликованы (symlink, copy, rsync), вы можете установить их с помощью cli команды:

$ php puli.phar publish --install
Installing /batman/blog/public into public_html/blog via symlink...

Мне кажется, Puli будет отличным решением для многих разработчиков модулей. Ведущим проекта является один из разработчиков Symfony — Bernhard Schussek. На данный момент версия puli 1.0.0-beta8. Сейчас имеется:

Composer plugin
Symfony Bidge
Twig Extension
Symfony Bundle
gulp-plugin

Источники:
docs.puli.io
github.com/puli
DrupalCon Barcelona 2015: Puli: PHP's Next Package Revolution

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (25):

  1. VolCh
    /#8619359 / +2

    Включение в блог Симфони имеет какое-то особое значение? Заточено под неё?

    • sashaaro
      /#8620925

      Ну в конце статьи написано, какое отношения это имеет к симфонии. Кстати, в symfony-standart 2.8 удалили AsseticBundle, и по умолчанию его не будет, вроде как в пользу grunt, gulp и т.п. В связи со скорым выходом symfony 3, неизвестно будет ли интеграция с puli

  2. nazarpc
    /#8619405 / +5

    Главная цель проекта — стандартизировать такие понятия как bundle, plugin, module для разных библиотек и фраймворков в одно общее независимое решение.

    Не зависимое ни от чего кроме ещё одного инструмента?
    Не буду прикреплять картинку про создание ещё одного стандарта)

  3. AmdY
    /#8619521 / +3

    Это антипаттерн — павлик морозов. Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.

    • Bal
      /#8619595

      >Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.

      Ну, например, composer из коробки сам не умеет работать с assets. И при создании своего проекта, использующего composer, приходится или обращаться к сторонним решениям (bower/node со всей монстроидальностью), или разруливать всё руками, в т.ч. следя за корректностью путей, или пользоваться пакетами третьих сторон под composer, управляющими assets. Идеальных среди них пока не встречал, но, возможно (только сегодня узнал и ещё не оценивал) puli может быть приличной альтернативой. А, может, очередным кривым менеджером ресурсов. В любом случае, менеджеры ресурсов под composer явно востребованы.

      • AmdY
        /#8619607 / +1

        Так он проблем не решает, а только добавляет, по функционалу это обычный finder, который ищет файлы по пулу путей. А проблемы ресурсов он никак не решает, только создаст лишнюю прослойку.

      • nazarpc
        /#8619651

        Хм… есть же плагин: github.com/francoispluchino/composer-asset-plugin
        Позволяет пакеты Bower/NPM определять как обычные Composer зависимости.

        • sashaaro
          /#8620909 / +1

          Прочитайте повнимательней или посмотрите документацию к puli. Эта библиотека решает другие проблемы.

    • Bal
      /#8619601

      Да, забыл добавить

      > Управление ресурсами — задача самих пакетов,

      Именно это и требуется. Но зачем в каждый пакет совать инструмент для работы с ресурсами, когда его можно вынести в отдельный пакет, который просто будет прописан в зависимостях нашего пакета? Для того и нужны пакетные системы. И получится всё удобно и красиво — есть наш пакет с ресурсами. Если сторонний пакет, позволяющий унифицировано работать с нашими ресурсами.

    • Fesor
      /#8619699

      что делать если нет фреймворка? Если у нас есть горка библиотек и мы всего лишь хотим взять компонент который будет управлять конфигами и прочими ресурсами?

    • sashaaro
      /#8621777 / +2

      Он не лезит в чужие внутренности. Только туда, где есть puli.json, то есть api для puli.

  4. vlreshet
    /#8619547 / +3

    А в чём изящность решения, в итоге? «У всех есть свои стандарты, но это не дело, поэтому мы придумали свой, надеемся все будут его юзать».

    • sashaaro
      /#8620891

      Я понимаю, что всем надоело навязывание сомнительных стандартов. Но здесь стандарт — это просто общее api для разработчиков, которые будут использовать puli.

  5. vlreshet
    /#8619571 / +2

    Очередной Symfony-way: для того чтобы читать файлы нужно писать целую отдельную библиотеку которую надо ещё подключить, сконфигурировать, и научиться пользоватся. Отлично! Больше абстракций и прослоек богу абстракций и прослоек.

    • sashaaro
      /#8620901 / +2

      Что-то похожего для php я не видел. Научиться пользоваться? Поверьте, это не так трудно. Puli.json по желанию.

    • kovalevsky
      /#8621999

      На самом деле, если развитие Ваших навыков не застопорилось на блоге Васи Пупкина, который показывает как подключить header.php и footer.php в скрипт, то в Symfony разбираться нечего. Там все и так предельно ясно и удобно (тут, возможно, дело на любителя) и в 99% случаев Вам будет достаточно API и Manual'ов с официального сайта :)

      • vlreshet
        /#8622073

        Ага, в симфони всё предельно ясно и удобно, а как же. Именно потому книга по симфони (книга (!) по фреймфорку (!)) размером больше чем книга о PHP. Не хочу начинать холивар, но симфони неоправданно переусложнён, монструозен, и избыточен. Использовать его в небольшом проекте — излишество, использовать в огромном — недостаток скорости, да и на действительно огромных проектах обычно пишутся фреймфорки специально заточенные под задачу.

        • Fesor
          /#8622323

          смотря какая (и по php и по symfony их уже не мало). Вон по Yii тоже книжки пишут, и? А сколько книжек по RoR.

        • VolCh
          /#8622979

          Использовать его в небольшом проекте — излишество

          Излишество в чём?
          использовать в огромном — недостаток скорости

          Скорости для чего?

          Вообще, что для вас значит «небольшой», «большой», «огромный»? Бизнес-логика (модель в MVC)? Чем она больше, тем, как правило, вклад фреймворка меньше как в общий размер кода, так и в скорость его выполнения.

          Как правило, универсальные фреймворки/библиотеки не нужны под узкие задачи под высокие нагрузки, когда с одной стороны 99% функциональности не нужно, а, с другой, на неё приходится 99% нагрузки. Если стоит задача как можно быстрее отдавать «Hello world» в ответ на любой единичный http-запрос на сервер, то тут даже использование nginx под вопросом — избыточен по функциональности и, наверняка, добавляет оверхид.

        • VolCh
          /#8622985 / +2

          Ага, в симфони всё предельно ясно и удобно, а как же. Именно потому книга по симфони (книга (!) по фреймфорку (!)) размером больше чем книга о PHP.


          Хороший фреймворк расширяет возможности языка. А значит и хорошая книга по его возможностям должна быть больше хорошей книги по этому языку.

        • kovalevsky
          /#8623117 / +2

          Symfony — это набор компонентов + Framework bundle. Если Вам оно слишком сложное и больше — берете и выбрасываете то, что кажется, ненужным. В чем проблема-то? Его по косточкам можно разобрать и собрать

  6. alexrett
    /#8619579 / +3

    Что-то я не совсем понял полезность данного «стандарта»… Рискую быть закиданным помидорами, но в чем профит в отличии от создаваемого compser'ом autoload.php? Там также собраны все пути до библиотек и файлов, а в настройках composer'a указываются пути к папкам сторонних библиотек и в случае их изменения они обновляются через composer.phar update. А если уж пришлось инклудить что-то ручками, так это зона ответственности разработчика и стандартизировать здесь, как минимум, странно. Может, я что-то не понял или не правильно готовлю?

    • VolCh
      /#8619633 / +2

      Как я понял, основное назначение — унификация доступа к ресурсам типа шаблонов, скриптов, фикстур и т. п.