-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
YiiFramework Yii PHP framework 1.1.11 is released
- Автор темы Redjik
- Дата начала
Ragazzo
TDD interested
Absinthe
Тем не менее, большинство фич 2го можно сделать разными экстеншенами и поведениями 1го, т.е. наверное только 2.0.2 или 2.0.5 будут более-менее стабильными, и то думаю это будет если повезет февраль наверное, хотя я в сроках не совсем компетентен, тут больше к core-девелоперам.
Тем не менее, большинство фич 2го можно сделать разными экстеншенами и поведениями 1го, т.е. наверное только 2.0.2 или 2.0.5 будут более-менее стабильными, и то думаю это будет если повезет февраль наверное, хотя я в сроках не совсем компетентен, тут больше к core-девелоперам.
Ragazzo
TDD interested
Ragazzo
TDD interested
Redjik
Да там много всего интересного поправили, например отправку файлов CHttpRequest::sendFile(), теперь всякий мусор не будет дампиться на onEndRequest и т п, сделали CFileHelper::removeDirectory(), улучшений по JsUI много, ну и от creocoder фишка чтобы динамически настраивать компоненты приложения. Очень много всего
Да там много всего интересного поправили, например отправку файлов CHttpRequest::sendFile(), теперь всякий мусор не будет дампиться на onEndRequest и т п, сделали CFileHelper::removeDirectory(), улучшений по JsUI много, ну и от creocoder фишка чтобы динамически настраивать компоненты приложения. Очень много всего
Очень логичный и обоснованный ответ. Я, как человек без опыта работы с YII, сразу же начну рекомендовать перейти обратноЕсть конечно, но каждый выбирает для себя сам же
A1x
Новичок
я как человек который сделал пару проектов на кохане и делающий сейчас проект на yii могу сказать что второй кажется мне интереснее
и переползти стоило. На кохане часто преследовала мысль что я написал бы лучше, с yii эта мысль наконец от меня отстала
Ragazzo
TDD interested
Всем подарок на НГ, вышел Yii 1.1.13
я решил свой форк yii сделать без 100% BC, а чтобы все было всерьез и надолго - в моей команде будет для этого человек
ближайшие планы:
* переписать CActiveRecord::$db на DI, подобный классу Фиксера, а то это ж просто писец феерический - объект соединения с базой в публичном статическом поле родительского класса моделей
* для findByPk() без JOIN-ов сделать поддержку Handler Socket (как вариант, попросить у Фиксера его либу)
* сделать поддержку репликации c поддержкой транзакций, подсказок (masterOnly, slavePrefered) и failover
* коллбек afterFindAll() - общий вызов для всех результатов поиска, а не для каждого поля отдельно
* возврат коллекций из findAll() и дефолтные null-объекты для отсутствующих связей чтобы было меньше лапшы if(NULL === $post->Author)
* Posts::model()->findAll()->asArray() - даже в 1.1
* кеш схем базы в php-файле, с байткод-кешем работает очень быстро, учитывает YII_DEBUG и миграции
более серьезные или менее нужные вещи:
* генератор action-ов для серверной стороны JSON-RPC2 и моделей для клиентской
* переписать немного CHtml на глифы по Банде 4х
* DI вместо private-полей в других нужных местах
* оптимизация CList*, уход от private $_d, $_c
* нормальная поддержка SOAP - как вариант, через генератор моделей
* исправить работу с PK таблицы в кишках AR, там щас скаляр/массив смешиваются
пишите чего еще серьезного надо
ближайшие планы:
* переписать CActiveRecord::$db на DI, подобный классу Фиксера, а то это ж просто писец феерический - объект соединения с базой в публичном статическом поле родительского класса моделей
* для findByPk() без JOIN-ов сделать поддержку Handler Socket (как вариант, попросить у Фиксера его либу)
* сделать поддержку репликации c поддержкой транзакций, подсказок (masterOnly, slavePrefered) и failover
* коллбек afterFindAll() - общий вызов для всех результатов поиска, а не для каждого поля отдельно
* возврат коллекций из findAll() и дефолтные null-объекты для отсутствующих связей чтобы было меньше лапшы if(NULL === $post->Author)
* Posts::model()->findAll()->asArray() - даже в 1.1
* кеш схем базы в php-файле, с байткод-кешем работает очень быстро, учитывает YII_DEBUG и миграции
более серьезные или менее нужные вещи:
* генератор action-ов для серверной стороны JSON-RPC2 и моделей для клиентской
* переписать немного CHtml на глифы по Банде 4х
* DI вместо private-полей в других нужных местах
* оптимизация CList*, уход от private $_d, $_c
* нормальная поддержка SOAP - как вариант, через генератор моделей
* исправить работу с PK таблицы в кишках AR, там щас скаляр/массив смешиваются
пишите чего еще серьезного надо
Redjik
Джедай-мастер
- Posts::model()->asArray()->findAll() - вот так тогда, смысл преобразовывать дефолтный объект в массив.
- Следствие из прошлого - в AR нужно будет учесть гетеры/сетеры для массивов.
ЗЫ. а про схему в php хранить - обидно даже, что сам не догадался до такого =)
ЗЫЫ. а CHtml пилить - ну не знаю, даже открыл 51ую страницу, посмотрел - обычный абстрактный класс + элементы стратегии, без переписывания большинства виджетов не будет иметь смысла. Идея хорошая, если параллельно от CHtml для BC делать.
- Следствие из прошлого - в AR нужно будет учесть гетеры/сетеры для массивов.
ЗЫ. а про схему в php хранить - обидно даже, что сам не догадался до такого =)
ЗЫЫ. а CHtml пилить - ну не знаю, даже открыл 51ую страницу, посмотрел - обычный абстрактный класс + элементы стратегии, без переписывания большинства виджетов не будет иметь смысла. Идея хорошая, если параллельно от CHtml для BC делать.
Ragazzo
TDD interested
grigori
Дак насколько знаю во 2ой вообще не будет коллекций(ну не так много, говорил Александр), т.к. из SPL будут брать что-то.
>>переписать CActiveRecord::$db на DI
дак то же самое только вид сбоку, что ты так встраиваешь CDbConnection проверяя класс, что просто будешь кидать туда объект, один фиг интерфейс будет у них одинаковым, в чем преимущество?
Кстати там с CMap и прочими коллекциями надо быть осторожнее т.к. у тех где есть метод mergeWith() он будет мерджить все даже если список readOnly (когда-то issue создавал на гитхабе, Кьен сказал что он так и задумывал).
Да вот еще, хорошо что пофиксили автолоадер для юнит тестов, ну там порядок просто поменяли, теперь юнитовский впереди стоит, а то раньше приходилось костыль-патч делать изза этого.
Дак насколько знаю во 2ой вообще не будет коллекций(ну не так много, говорил Александр), т.к. из SPL будут брать что-то.
>>переписать CActiveRecord::$db на DI
дак то же самое только вид сбоку, что ты так встраиваешь CDbConnection проверяя класс, что просто будешь кидать туда объект, один фиг интерфейс будет у них одинаковым, в чем преимущество?
Кстати там с CMap и прочими коллекциями надо быть осторожнее т.к. у тех где есть метод mergeWith() он будет мерджить все даже если список readOnly (когда-то issue создавал на гитхабе, Кьен сказал что он так и задумывал).
Да вот еще, хорошо что пофиксили автолоадер для юнит тестов, ну там порядок просто поменяли, теперь юнитовский впереди стоит, а то раньше приходилось костыль-патч делать изза этого.
народ, вы слишком на своей волне, все будет лучше
А я хочу "правильно": возвращать коллекцию, из которой по lazy load генерить объекты записей, или брать сырой массив по toArray()
Для результатов запроса сеттер не нужен.
Ragazzo,
1. коллекция - это паттерн, а не класс.
2. я тоже думаю про SplFixedArray, еще не проектировал схему
3. про $db - фиги разные потому что в разных моделях смогут лежать разные объекты
убирается связанность и появляются возможности
можно будет разделить AR::$db на разные коннекты для записи и чтения конкретных моделей (не все таблицы реплицируются), можно делать пуллы соединений для репликации
4. Я хочу уйти от этих долбаных CList и CMap с доступом к записям через геттер - там идет вызов колбеков на каждом шаге в тех 99.99% случаев, когда этих колбеков нет. Тормоза от них нереальные - я открывал тикет 2 года назад, сделал сравнительные тесты, Тян послал меня на со словами BC break. Сделаю с максимальной совместимостью, конечно, но без учета 1 случая на миллион.
asArray()->FindAll() они хотят в 2ке, и это "смешались кони, люди".
А я хочу "правильно": возвращать коллекцию, из которой по lazy load генерить объекты записей, или брать сырой массив по toArray()
Для результатов запроса сеттер не нужен.
Ну да, это low priority, просто раздражает. Надо глянуть как Sad Spirit сделал в QuickForms.
Ragazzo,
1. коллекция - это паттерн, а не класс.
2. я тоже думаю про SplFixedArray, еще не проектировал схему
3. про $db - фиги разные потому что в разных моделях смогут лежать разные объекты
убирается связанность и появляются возможности
можно будет разделить AR::$db на разные коннекты для записи и чтения конкретных моделей (не все таблицы реплицируются), можно делать пуллы соединений для репликации
4. Я хочу уйти от этих долбаных CList и CMap с доступом к записям через геттер - там идет вызов колбеков на каждом шаге в тех 99.99% случаев, когда этих колбеков нет. Тормоза от них нереальные - я открывал тикет 2 года назад, сделал сравнительные тесты, Тян послал меня на со словами BC break. Сделаю с максимальной совместимостью, конечно, но без учета 1 случая на миллион.