Comments 38
Отличный подарок к Новогому Году, хоть и сложно воспринимать его утром первого января.
Спасибо. Осталось удержаться и не начать обновлять всё сейчас, а дать себе отдохнуть.
Это прекрасная новость утром 1го… раз тут такие замечательные плюшки появились, но сначала надо до конца с коханой разобраться…
'jobs'=>array(self::HAS_MANY, 'Job', array('date' => 'target_date'))
вот этого реально не хватало иногда, спасибо.
вот этого реально не хватало иногда, спасибо.
Отличная новость, попробуем.
Основные изменения только в ActiveRecord :(
Есть какие-нибудь пожелания?
Сжатие asset'ов из коробки. Из глобально-масштабного поддержку HTTP Streaming, например.
assetы можно сжимать посредствам расширений — насколько я помню есть парочка очень неплохих. По поводу HTTP Streaming из коробки — это довольно специфичная штука, и опять же тут стоит вынести это дело в стороннее расширение. Не помню точно, но вроде бы что-то такое тоже есть.
Ваше предложение — остановить развитие Yii? С такой логикой миграции и все, кроме роутов/AR/шаблонов надо в расширения вынести. Существенную часть extendedclientscript, между прочим, написал автор этих строк :)
Нет, мое предложение — совершенствовать имеющийся функционал, развивать компоненты WEb сервисов, пересмотреть принцыпы для работы с формами, переписать CDbCriteria… там очень много чего что можно допиливать, додумывать, доделывать. Не стоит так экспессивно реагировать. Возможно сжатие и можно внести в состав фреймворка, так как этот функционал востребован, но вот HTTP Streaming — вам никто собственно не мешает реализовать данный функционал и предложить внедрить его в состав фреймворка. Но все же это уже довольно специфичный функционал, не настолько востребованный. Такие вещи следует реализовывать в качестве расширений. А вот в будущем, когда данный функционал будет пользоваться спросом, его можно включить в состав фреймворка. Все меняется со временем, и пытаться охватить все и вся, имея еще огромный TODO список, смысла не имеет, дла этого и придумывались репозитории расширений и прочего. Пока нововведений недопиленый хватает — браться за что-то еще смысла нету.
Будьте осторожны при использовании yiilite.php: он вызывает ошибку при использовании CLocale, а конкретнее ошибка возникает в конструкторе, т.к. при создании экземпляра CLocale путь к данным локали считается от расположения файла, содержащего класс, а для /i18n/CLocale.php и /yiilite.php пути, естественно, разные.
Починить просто: удалите код класса CLocale из yiilite.php. На официальном форуме я уже про это написал.
Починить просто: удалите код класса CLocale из yiilite.php. На официальном форуме я уже про это написал.
О! А продублировать сюда можно http://code.google.com/p/yii/issues/list? Спасибо.
У меня нет аккаунта на google, поэтому опубликовал в Bug Discussions
Спасибо. Я перепостил в трекер уже.
И вам спасибо!
На будующее: куда мне лучше публиковать найденные ошибки — в данный раздел форума, или можно публиковать в соотв. разделе формума на yiiframework.ru по-русски (с английским у меня не очень)? Стоит ли дублировать репорты на форумах? не уверен что хочу регистрироваться в google, с их подтверждениями, использующими мобильник, хотя вот теперь задумался.
Будет ли выложена исправленная версия под текущим номером, или исправление будет в следующей версии?
На будующее: куда мне лучше публиковать найденные ошибки — в данный раздел форума, или можно публиковать в соотв. разделе формума на yiiframework.ru по-русски (с английским у меня не очень)? Стоит ли дублировать репорты на форумах? не уверен что хочу регистрироваться в google, с их подтверждениями, использующими мобильник, хотя вот теперь задумался.
Будет ли выложена исправленная версия под текущим номером, или исправление будет в следующей версии?
>Рассмотрим наиболее интересные изменения.
Наиболее интересно посмотреть на тех, кто 1 января что-то релизит :)
Наиболее интересно посмотреть на тех, кто 1 января что-то релизит :)
>> Возможность сделать JOIN между моделями по заданным ключам
>> создание отношений по заданной паре PK->FK не опираясь на схему данных
а к чему это? в каком кейзе это крайне полезно (необходимо)?
>> создание отношений по заданной паре PK->FK не опираясь на схему данных
а к чему это? в каком кейзе это крайне полезно (необходимо)?
Бывают кривые БД, которые остаются в наследство. При нормальном проектировании такого, как правило, не бывает.
трудно себе предстовляю кейс когда досталась в наследство структура БД которую нельзя поменять, но проект переписывается с начала с использованием фреймворка.
В общем я к тому что эта фича очень «скользкая», теперь как раз таки может появиться достаточное кол-во кода без нормальной структуры бд.
Хотя возможно допускаю иногда действительно это может пригодиться.
В общем я к тому что эта фича очень «скользкая», теперь как раз таки может появиться достаточное кол-во кода без нормальной структуры бд.
Хотя возможно допускаю иногда действительно это может пригодиться.
Вот Вам пример: у меня есть биллинг, создатель которого, судя по всему, не слышал о Foreign Key. Мне для него надо сделать юзерскую морду («личный кабинет»). Вот как раз и пригодилось.
Например, часто одной базой пользуются несколько приложений. Одно из них уже существовало. Второе — наше. Базу менять нельзя из за обратной совместимости.
Проект переписывается поэтапно, то есть параллельно работают и новые куски, и стареы.
сейчас проверил новый дистрибутив, и удивился его размеру, с читай в половина раза больше стал. Оказывается разбухла директория i18n
было
3,78 МБ (Файлов: 616; папок: 2)
стало
11,6 МБ (Файлов: 666; папок: 2)
было
3,78 МБ (Файлов: 616; папок: 2)
стало
11,6 МБ (Файлов: 666; папок: 2)
Sign up to leave a comment.
Yii 1.1.9