Puli — это инструмент, позволяющий универсально управлять ресурсами в 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.
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.
Теперь пользователь должен указать как минимум один 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)
nazarpc
19.10.2015 17:00+5Главная цель проекта — стандартизировать такие понятия как bundle, plugin, module для разных библиотек и фраймворков в одно общее независимое решение.
Не зависимое ни от чего кроме ещё одного инструмента?
Не буду прикреплять картинку про создание ещё одного стандарта)
Fesor
19.10.2015 19:59webmozart.io/blog/2013/06/19/the-power-of-uniform-resource-location-in-php — лучше предысторию все же почитать.
AmdY
19.10.2015 18:08+3Это антипаттерн — павлик морозов. Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.
Bal
19.10.2015 18:57>Управление ресурсами — задача самих пакетов, они должны публиковать ресурсы через api фреймворка, а не сторонний пакет который лазит в чужие внутренности.
Ну, например, composer из коробки сам не умеет работать с assets. И при создании своего проекта, использующего composer, приходится или обращаться к сторонним решениям (bower/node со всей монстроидальностью), или разруливать всё руками, в т.ч. следя за корректностью путей, или пользоваться пакетами третьих сторон под composer, управляющими assets. Идеальных среди них пока не встречал, но, возможно (только сегодня узнал и ещё не оценивал) puli может быть приличной альтернативой. А, может, очередным кривым менеджером ресурсов. В любом случае, менеджеры ресурсов под composer явно востребованы.AmdY
19.10.2015 19:12+1Так он проблем не решает, а только добавляет, по функционалу это обычный finder, который ищет файлы по пулу путей. А проблемы ресурсов он никак не решает, только создаст лишнюю прослойку.
nazarpc
19.10.2015 20:02Хм… есть же плагин: github.com/francoispluchino/composer-asset-plugin
Позволяет пакеты Bower/NPM определять как обычные Composer зависимости.
sashaaro
20.10.2015 16:45+1Прочитайте повнимательней или посмотрите документацию к puli. Эта библиотека решает другие проблемы.
Bal
19.10.2015 18:59Да, забыл добавить
> Управление ресурсами — задача самих пакетов,
Именно это и требуется. Но зачем в каждый пакет совать инструмент для работы с ресурсами, когда его можно вынести в отдельный пакет, который просто будет прописан в зависимостях нашего пакета? Для того и нужны пакетные системы. И получится всё удобно и красиво — есть наш пакет с ресурсами. Если сторонний пакет, позволяющий унифицировано работать с нашими ресурсами.
Fesor
19.10.2015 20:39что делать если нет фреймворка? Если у нас есть горка библиотек и мы всего лишь хотим взять компонент который будет управлять конфигами и прочими ресурсами?
sashaaro
21.10.2015 10:37+2Он не лезит в чужие внутренности. Только туда, где есть puli.json, то есть api для puli.
vlreshet
19.10.2015 18:29+3А в чём изящность решения, в итоге? «У всех есть свои стандарты, но это не дело, поэтому мы придумали свой, надеемся все будут его юзать».
sashaaro
20.10.2015 16:38Я понимаю, что всем надоело навязывание сомнительных стандартов. Но здесь стандарт — это просто общее api для разработчиков, которые будут использовать puli.
vlreshet
19.10.2015 18:42+2Очередной Symfony-way: для того чтобы читать файлы нужно писать целую отдельную библиотеку которую надо ещё подключить, сконфигурировать, и научиться пользоватся. Отлично! Больше абстракций и прослоек богу абстракций и прослоек.
sashaaro
20.10.2015 16:42+2Что-то похожего для php я не видел. Научиться пользоваться? Поверьте, это не так трудно. Puli.json по желанию.
kovalevsky
21.10.2015 12:49На самом деле, если развитие Ваших навыков не застопорилось на блоге Васи Пупкина, который показывает как подключить header.php и footer.php в скрипт, то в Symfony разбираться нечего. Там все и так предельно ясно и удобно (тут, возможно, дело на любителя) и в 99% случаев Вам будет достаточно API и Manual'ов с официального сайта :)
vlreshet
21.10.2015 13:17Ага, в симфони всё предельно ясно и удобно, а как же. Именно потому книга по симфони (книга (!) по фреймфорку (!)) размером больше чем книга о PHP. Не хочу начинать холивар, но симфони неоправданно переусложнён, монструозен, и избыточен. Использовать его в небольшом проекте — излишество, использовать в огромном — недостаток скорости, да и на действительно огромных проектах обычно пишутся фреймфорки специально заточенные под задачу.
Fesor
21.10.2015 16:17смотря какая (и по php и по symfony их уже не мало). Вон по Yii тоже книжки пишут, и? А сколько книжек по RoR.
VolCh
22.10.2015 02:19Использовать его в небольшом проекте — излишество
Излишество в чём?
использовать в огромном — недостаток скорости
Скорости для чего?
Вообще, что для вас значит «небольшой», «большой», «огромный»? Бизнес-логика (модель в MVC)? Чем она больше, тем, как правило, вклад фреймворка меньше как в общий размер кода, так и в скорость его выполнения.
Как правило, универсальные фреймворки/библиотеки не нужны под узкие задачи под высокие нагрузки, когда с одной стороны 99% функциональности не нужно, а, с другой, на неё приходится 99% нагрузки. Если стоит задача как можно быстрее отдавать «Hello world» в ответ на любой единичный http-запрос на сервер, то тут даже использование nginx под вопросом — избыточен по функциональности и, наверняка, добавляет оверхид.
VolCh
22.10.2015 02:25+2Ага, в симфони всё предельно ясно и удобно, а как же. Именно потому книга по симфони (книга (!) по фреймфорку (!)) размером больше чем книга о PHP.
Хороший фреймворк расширяет возможности языка. А значит и хорошая книга по его возможностям должна быть больше хорошей книги по этому языку.
kovalevsky
22.10.2015 09:01+2Symfony — это набор компонентов + Framework bundle. Если Вам оно слишком сложное и больше — берете и выбрасываете то, что кажется, ненужным. В чем проблема-то? Его по косточкам можно разобрать и собрать
alexrett
19.10.2015 18:49+3Что-то я не совсем понял полезность данного «стандарта»… Рискую быть закиданным помидорами, но в чем профит в отличии от создаваемого compser'ом autoload.php? Там также собраны все пути до библиотек и файлов, а в настройках composer'a указываются пути к папкам сторонних библиотек и в случае их изменения они обновляются через composer.phar update. А если уж пришлось инклудить что-то ручками, так это зона ответственности разработчика и стандартизировать здесь, как минимум, странно. Может, я что-то не понял или не правильно готовлю?
VolCh
19.10.2015 19:46+2Как я понял, основное назначение — унификация доступа к ресурсам типа шаблонов, скриптов, фикстур и т. п.
VolCh
Включение в блог Симфони имеет какое-то особое значение? Заточено под неё?
Fesor
есть бандл, ну и автор puli — webmozart, так что… почему бы и да?
sashaaro
Ну в конце статьи написано, какое отношения это имеет к симфонии. Кстати, в symfony-standart 2.8 удалили AsseticBundle, и по умолчанию его не будет, вроде как в пользу grunt, gulp и т.п. В связи со скорым выходом symfony 3, неизвестно будет ли интеграция с puli