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

[VolCh]

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

[Fesor]

есть бандл, ну и автор puli — webmozart, так что… почему бы и да?

[sashaaro]

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

[nazarpc]

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

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

[Fesor]

webmozart.io/blog/2013/06/19/the-power-of-uniform-resource-location-in-php — лучше предысторию все же почитать.

[AmdY]

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

[Bal]

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

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

[AmdY]

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

[Bal]

Так я писал не про топикстартовый пакет, а отвечал на обобщённое утверждение о управлении ресурсами вообще.

[nazarpc]

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

[sashaaro]

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

[Bal]

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

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

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

[Fesor]

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

[sashaaro]

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

[sashaaro]

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

[sashaaro]

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

[kovalevsky]

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

[Fesor]

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

[VolCh]

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

Излишество в чём?

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

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

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

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

[VolCh]

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

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

[kovalevsky]

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

[alexrett]

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

[VolCh]

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