Тут та же ситуация, что с конфигурацией фаервола… или прав доступа: лучше запретить всё, а потом разрешать, чем разрешить всё а потом затыкать дыры. В CI гораздо проще случайно оставить action открытым.
Я не про новые библиотеки, а про перекрытие стандартных. Например, нужно для email организовать очередь, а не отправлять сразу. Код уже написан. Что делать?
Всё = всё, что потребуется из указанных в конфигурации путей в указанном порядке.
> что мешает в CI не работать с базой в модели
Мешает странный API. Если не передать третьему параметру false при загрузке модели — произойдёт инициализация БД.
Про MY_ вы не так поняли. В CI можно было перекрыть класс ядра только один раз и только с одним определённым именем. Отсюда многочисленные одноимённые классы с разным функционалом в wiki и на форумах.
Я от Zend-а как от full stack фреймворка именно поэтому отказался (может сейчас там всё лучше… не знаю). А вот как Enterprise-версию PEAR использую его с большим удовольствием.
Занятно… если верно помню, смысл singnal/slot или observer был в том, что любой компонент может без предварительной регистрации послать любой event. И любой же компонент может любой event отработать. Если в данном случае что-то иное, то скорее всего это не signal/slot…
Тут та же ситуация, что с конфигурацией фаервола… или прав доступа: лучше запретить всё, а потом разрешать, чем разрешить всё а потом затыкать дыры. В CI гораздо проще случайно оставить action открытым.
2. По сути Yii::app() — это тот же get_instance().
> что мешает в CI не работать с базой в модели
Мешает странный API. Если не передать третьему параметру false при загрузке модели — произойдёт инициализация БД.
Про MY_ вы не так поняли. В CI можно было перекрыть класс ядра только один раз и только с одним определённым именем. Отсюда многочисленные одноимённые классы с разным функционалом в wiki и на форумах.
Dwoo… может сразу Quicky?