Все верно.
Просто привычка от ZF использовать встроенные функции, даже когда есть альтернативы. Такая же как и использовать Yii::app()->request->getPost() вместо $_POST. Других причин нет.
Зачем эта функция нужна в Yii и как сюда попала лучше спросить у автора фреймворка. Может он посчитал что она быстрее будет работать?! А может просто решил "пусть будет" )). В ZF принято всегда пользоваться функциями фреймворка а не нативного языка. В Yii таких рекомендаций нет, и каждый ложит что угодно куда угодно и использует что угодно где угодно.
Я бы добавил что те которые испытывают имеют не один сервер за пазухой. И нагрузка между этими серверами балансируется. А значит можно вернутся к разговору о том что сессии это вообще не проблема. Если, конечно, в них не хранить том «Война и Мир» ))
При грамотном проектировании ничего на них не сэкономишь. А при не грамотном лучше оптимизировать запросы к БД. Потому как чаще всего там кроются все проблемы.
Захожу в группу "ООО Интера" снимаю галочку с "Запретить вход", Ставлю галку на Разрешить VPN из интернет у Иванов Андрей Арнольдович — результат "Не указан".
OS Linux Ubuntu x64 12.04 + Firefox 14.0.1 (А еще та же фигня в убунте с Chrome, IE, Safari) — Я что то делаю не так или их веб морда глючит?
С переменной окружения системы это самый очевидный вариант. Все просто и довольно гибко. Как говорит принцип Лезвия Оккама — «Самое простое — самое верное» :)
Все решается просто.
Во первых нужно учитывать что для CLI Yii имеет свой конфиг, а значит что бы разбить конфигурацию для вызова из консоли требуется привести ее в соответствующий вид.
Во вторых переменную окружения можно добивать в систему и она таким же образом будет видна в Yii.
В Linux переменная окружения в систему добавляется так "export APPLICATION_ENV=devel;". В Windows это сделать не сложнее. Соответственно быстрый вызов скрипта из консоли Linux может выглядеть так "export APPLICATION_ENV=devel; ./yiic test". Главное не забываете что для того что бы это все заработало вам нужно изменить соответствующим образом файл /protected/yiic.php вашего скрипта.
Все делается по аналогии со статьей, только переменная окружения добавляется не в Apache а в саму систему. Если кому интересно могу напечатать отдельный очерк по этой теме.
Тут речь не о том что бы вносить изменения в зависимые от версии конфиги. Речь о том что когда работаешь над проектом его приходится выкладывать на продакшен сервер. И даже минимально но приходится менять настройки БД. Иногда обновление конфига становится проблемной темой.
Помимо настроек БД там могут прописываться десяток путей к различным директориям и другие всевозможные персональные конфигурации.
А еще у проекта бывает не один разработчик а команда. Несколько программеров, тестеры, фокус группы… Часто каждая группа использует свой сервер. В этих условиях конфиги лучше иметь каждому свой, но позволить наследовать основной — эталонный.
Подходы которые я видел ранее с указанием имени или IP сервера менее гибкие. Хотя бы по той причине что имена у серверов (как ни крути) но могут пересекаться, не говоря уже о куче localhost`ов и 127.0.0.1`ов. А в описанном мною способе, который кстати используется в Symphony и ZF, достаточно определить значение переменной APPLICATION_ENV для сайта и программа уже сама подтянет соответствующий конфиг переопределив нужные параметры у эталона. И не нужно ни регепсов, ни сравнений имени, ни if`ов и switch`ей… Даже не нужно применять хитроумные шаблоны проектирования и это гораздо проще чем использовать разные конфигурации в ветках на git. Кстати для меня лично загадка почему подобный подход ранее не был описан ну или очень далеко спрятан.
Про эту особенность я не слышал. Спасибо за наводку. Буду иметь ввиду. Что касается приведенного примера, то можно для продакшена использовать файл без слияния, а остальным переопределять именно конфигурацию продакшена. Т.е. в моем примере основная конфигурация будет не в main.php а production.php. Конфиги типа devel.php будут переопределять уже конфигурацию production.php. По идее это должно решить проблему с тормозами и сохранить простоту. Как думаете?
Просто привычка от ZF использовать встроенные функции, даже когда есть альтернативы. Такая же как и использовать Yii::app()->request->getPost() вместо $_POST. Других причин нет.
Зачем эта функция нужна в Yii и как сюда попала лучше спросить у автора фреймворка. Может он посчитал что она быстрее будет работать?! А может просто решил "пусть будет" )). В ZF принято всегда пользоваться функциями фреймворка а не нативного языка. В Yii таких рекомендаций нет, и каждый ложит что угодно куда угодно и использует что угодно где угодно.
OS Linux Ubuntu x64 12.04 + Firefox 14.0.1 (А еще та же фигня в убунте с Chrome, IE, Safari) — Я что то делаю не так или их веб морда глючит?
Во первых нужно учитывать что для CLI Yii имеет свой конфиг, а значит что бы разбить конфигурацию для вызова из консоли требуется привести ее в соответствующий вид.
Во вторых переменную окружения можно добивать в систему и она таким же образом будет видна в Yii.
В Linux переменная окружения в систему добавляется так "export APPLICATION_ENV=devel;". В Windows это сделать не сложнее. Соответственно быстрый вызов скрипта из консоли Linux может выглядеть так "export APPLICATION_ENV=devel; ./yiic test". Главное не забываете что для того что бы это все заработало вам нужно изменить соответствующим образом файл /protected/yiic.php вашего скрипта.
Все делается по аналогии со статьей, только переменная окружения добавляется не в Apache а в саму систему. Если кому интересно могу напечатать отдельный очерк по этой теме.
Помимо настроек БД там могут прописываться десяток путей к различным директориям и другие всевозможные персональные конфигурации.
А еще у проекта бывает не один разработчик а команда. Несколько программеров, тестеры, фокус группы… Часто каждая группа использует свой сервер. В этих условиях конфиги лучше иметь каждому свой, но позволить наследовать основной — эталонный.
Подходы которые я видел ранее с указанием имени или IP сервера менее гибкие. Хотя бы по той причине что имена у серверов (как ни крути) но могут пересекаться, не говоря уже о куче localhost`ов и 127.0.0.1`ов. А в описанном мною способе, который кстати используется в Symphony и ZF, достаточно определить значение переменной APPLICATION_ENV для сайта и программа уже сама подтянет соответствующий конфиг переопределив нужные параметры у эталона. И не нужно ни регепсов, ни сравнений имени, ни if`ов и switch`ей… Даже не нужно применять хитроумные шаблоны проектирования и это гораздо проще чем использовать разные конфигурации в ветках на git. Кстати для меня лично загадка почему подобный подход ранее не был описан ну или очень далеко спрятан.