Как насчет запихнуть весь фреймворк в phar архив?

[alexzv]

Собственно по теме. Как думаете, идея имеет право на существование? Ссылка про phar: http://habrahabr.ru/blogs/php/118269/

[Ekstazi]

Думаю пока еще рано говорить об этом.

[Nihisil]

Когда-нибудь точно будет, т.к. штука эта удобная

[mrix]

Зачем?

С тем же успехом можно упаковать в архив. При каждом выполнении распаковывать, а потом удалять.
Мне кажется, это нужно для других целей.

[radamir]

Хорошая и полезная идея. И спрашивать не о чем, запихни в phar и юзай. Перед запихиванием можно файлы php, css, js минифицировать.

[ksnk]

А про yiilite слыхали? Не одно и то-же получится?
К тому-же, упаковывать css и js в один флакон к php - неэффективно, не буду пояснять почему

[radamir]

А про yiilite слыхали? Не одно и то-же получится?
К тому-же, упаковывать css и js в один флакон к php - неэффективно, не буду пояснять почему

1. Про yiilite.php cлыхал и использую. Имеено его я ложу в phar а 50+ файлов которые он заменяет не ложу.
2. Получается не одно и то же.
3. Если не поясните, то это останется тайной по крайней мере для меня. Css и js файлы прекрсано работают из phar через assetManager.

[ksnk]

2. Получается не одно и то же.
3. Если не поясните, то это останется тайной по крайней мере для меня. Css и js файлы прекрсано работают из phar через assetManager.

разбивка на множество разных файлов, как она существует в теперешнем виде, возникла не от общей тупости исполнителей, а в силу важных и достаточно убедительных причин. Работать с файлом, для отдачи его без обработки клиенту - эффективнее и проще не на PHP, который будет вызван через несколько тяжелых посредников, а самому серверу. Быстро и без расхода ресурсов. Так что паковать CSS и JS в архив, а потом гордится скоростью обработки получившегося бутерброда не стоит.

Так что единственные кандидаты на упаковку - файлы, которые обрабатываются PHP. - сами скрипты и их инклюды. Их всех вполне можно упаковать в один файл. Yiilite, imho, именно для этого и сделан.

[radamir]

разбивка на множество разных файлов, как она существует в теперешнем виде, возникла не от общей тупости исполнителей, а в силу важных и достаточно убедительных причин. Работать с файлом, для отдачи его без обработки клиенту - эффективнее и проще не на PHP, который будет вызван через несколько тяжелых посредников, а самому серверу. Быстро и без расхода ресурсов. Так что паковать CSS и JS в архив, а потом гордится скоростью обработки получившегося бутерброда не стоит.

Так что единственные кандидаты на упаковку - файлы, которые обрабатываются PHP. - сами скрипты и их инклюды. Их всех вполне можно упаковать в один файл. Yiilite, imho, именно для этого и сделан.

1. Согласен, что разбивка на множество файлов очень важна при разработке и отладки и не считаю исполнителей тупыми.
2. Согласен, работать с файлом, для отдачи его без обработки клиенту - эффективнее и проще не на PHP. Работая c сss и js файлами через assetManager мы делегируем их раздачу веб-серверу.
3. Паковать можно все файлы фреймворка без потери производительности.

[ksnk]

Работая c сss и js файлами через assetManager мы делегируем их раздачу веб-серверу.

Хм... тогда что такое assetManager?

[radamir]

Хм... тогда что такое assetManager?

http://yiiframework.ru/doc/cookbook/ru/core.assets
http://www.yiiframework.com/doc/api/1.1/CAssetManager

[ksnk]

А я уж подумал, что-то другое
Для работы assetMagnager нужна связка apache, php, и yii. Почему эта связка кажется вам более быстрой, чем простой apache, или даже, как обычно бывает, nginx?

[radamir]

1. Потому что после того как ресурс опубликован php и yii уже не нужен, потому что его дальнейшей раздачей занимается apache или да же nginx.
2. Так как фреймворк и css и js-файлы в нем находятся обычно вне корневой папки сайта у вас другого выбора для работы с ними нет.

[ksnk]

1. Потому что после того как ресурс опубликован php и yii уже не нужен, потому что его дальнейшей раздачей занимается apache или да же nginx.

Тоесть фреймворк инсталлируется на сервере и живет уже дальше нормальной жизнью?

[ksnk]

Так как фреймворк и css и js-файлы в нем находятся обычно вне корневой папки сайта у вас другого выбора для работы с ними нет.

Ах вот оно как? позиция понятна.
Перекомпоновать используемые модули, так, чтобы css и скрипты попали в правильное место не удается?

[radamir]

Перекомпоновать используемые модули, так, чтобы css и скрипты попали в правильное место не удается?

Какие модули? Мы говорим о фреймворки. Перекомпановывать что-то в нем не вижу нужды.