Пользователь
0,0
рейтинг
19 октября 2015 в 15:14

Разработка → Puli: Управление ресурсами в php приложениях из песочницы

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
Александр @sashaaro
карма
8,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +2
    Включение в блог Симфони имеет какое-то особое значение? Заточено под неё?
    • 0
      есть бандл, ну и автор puli — webmozart, так что… почему бы и да?
    • 0
      Ну в конце статьи написано, какое отношения это имеет к симфонии. Кстати, в symfony-standart 2.8 удалили AsseticBundle, и по умолчанию его не будет, вроде как в пользу grunt, gulp и т.п. В связи со скорым выходом symfony 3, неизвестно будет ли интеграция с puli
  • +5
    Главная цель проекта — стандартизировать такие понятия как bundle, plugin, module для разных библиотек и фраймворков в одно общее независимое решение.

    Не зависимое ни от чего кроме ещё одного инструмента?
    Не буду прикреплять картинку про создание ещё одного стандарта)
  • +3
    Это антипаттерн — павлик морозов. Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.
    • 0
      >Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.

      Ну, например, composer из коробки сам не умеет работать с assets. И при создании своего проекта, использующего composer, приходится или обращаться к сторонним решениям (bower/node со всей монстроидальностью), или разруливать всё руками, в т.ч. следя за корректностью путей, или пользоваться пакетами третьих сторон под composer, управляющими assets. Идеальных среди них пока не встречал, но, возможно (только сегодня узнал и ещё не оценивал) puli может быть приличной альтернативой. А, может, очередным кривым менеджером ресурсов. В любом случае, менеджеры ресурсов под composer явно востребованы.
      • +1
        Так он проблем не решает, а только добавляет, по функционалу это обычный finder, который ищет файлы по пулу путей. А проблемы ресурсов он никак не решает, только создаст лишнюю прослойку.
        • 0
          Так я писал не про топикстартовый пакет, а отвечал на обобщённое утверждение о управлении ресурсами вообще.
      • 0
        Хм… есть же плагин: github.com/francoispluchino/composer-asset-plugin
        Позволяет пакеты Bower/NPM определять как обычные Composer зависимости.
        • +1
          Прочитайте повнимательней или посмотрите документацию к puli. Эта библиотека решает другие проблемы.
    • 0
      Да, забыл добавить

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

      Именно это и требуется. Но зачем в каждый пакет совать инструмент для работы с ресурсами, когда его можно вынести в отдельный пакет, который просто будет прописан в зависимостях нашего пакета? Для того и нужны пакетные системы. И получится всё удобно и красиво — есть наш пакет с ресурсами. Если сторонний пакет, позволяющий унифицировано работать с нашими ресурсами.
    • 0
      что делать если нет фреймворка? Если у нас есть горка библиотек и мы всего лишь хотим взять компонент который будет управлять конфигами и прочими ресурсами?
    • +2
      Он не лезит в чужие внутренности. Только туда, где есть puli.json, то есть api для puli.
  • +3
    А в чём изящность решения, в итоге? «У всех есть свои стандарты, но это не дело, поэтому мы придумали свой, надеемся все будут его юзать».
    • 0
      Я понимаю, что всем надоело навязывание сомнительных стандартов. Но здесь стандарт — это просто общее api для разработчиков, которые будут использовать puli.
  • +2
    Очередной Symfony-way: для того чтобы читать файлы нужно писать целую отдельную библиотеку которую надо ещё подключить, сконфигурировать, и научиться пользоватся. Отлично! Больше абстракций и прослоек богу абстракций и прослоек.
    • +2
      Что-то похожего для php я не видел. Научиться пользоваться? Поверьте, это не так трудно. Puli.json по желанию.
    • 0
      На самом деле, если развитие Ваших навыков не застопорилось на блоге Васи Пупкина, который показывает как подключить header.php и footer.php в скрипт, то в Symfony разбираться нечего. Там все и так предельно ясно и удобно (тут, возможно, дело на любителя) и в 99% случаев Вам будет достаточно API и Manual'ов с официального сайта :)
      • 0
        Ага, в симфони всё предельно ясно и удобно, а как же. Именно потому книга по симфони (книга (!) по фреймфорку (!)) размером больше чем книга о PHP. Не хочу начинать холивар, но симфони неоправданно переусложнён, монструозен, и избыточен. Использовать его в небольшом проекте — излишество, использовать в огромном — недостаток скорости, да и на действительно огромных проектах обычно пишутся фреймфорки специально заточенные под задачу.
        • 0
          смотря какая (и по php и по symfony их уже не мало). Вон по Yii тоже книжки пишут, и? А сколько книжек по RoR.
        • 0
          Использовать его в небольшом проекте — излишество

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

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

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

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


          Хороший фреймворк расширяет возможности языка. А значит и хорошая книга по его возможностям должна быть больше хорошей книги по этому языку.
        • +2
          Symfony — это набор компонентов + Framework bundle. Если Вам оно слишком сложное и больше — берете и выбрасываете то, что кажется, ненужным. В чем проблема-то? Его по косточкам можно разобрать и собрать
  • +3
    Что-то я не совсем понял полезность данного «стандарта»… Рискую быть закиданным помидорами, но в чем профит в отличии от создаваемого compser'ом autoload.php? Там также собраны все пути до библиотек и файлов, а в настройках composer'a указываются пути к папкам сторонних библиотек и в случае их изменения они обновляются через composer.phar update. А если уж пришлось инклудить что-то ручками, так это зона ответственности разработчика и стандартизировать здесь, как минимум, странно. Может, я что-то не понял или не правильно готовлю?
    • +2
      Как я понял, основное назначение — унификация доступа к ресурсам типа шаблонов, скриптов, фикстур и т. п.
  • 0
    Подкаст с автором про сабж: voicesoftheelephpant.com/2015/10/09/interview-with-bernhard-schussek

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