Как стать автором
Обновить

Комментарии 110

Не подскажете ссылку на описание особенностей?
Прям «рекламного» списка фич на Yii 2, я к сожалению нигде не нашел, но есть вполне проясняющий ситуацию roadmap. Надеюсь это то что вам надо :)
НЛО прилетело и опубликовало эту надпись здесь
Да ладно? Грешки там конечно есть, но код там довольно хороший;)
Думаю, страшно от форматирования кода. Это правда.
НЛО прилетело и опубликовало эту надпись здесь
Ты видимо не видел страшно выглядящий код;)
НЛО прилетело и опубликовало эту надпись здесь
Я не имел ввиду фреймворки конкретно.
Но если нужен популярный пример, то можно посмотреть CMS-ки аля джумла или битрикс. При одно взгляде появляются рвотные позывы.

YiiBase::import конечно большой и имеет много вложенных конструкций, но в современный реалиях php выглядит ни как не страшно.
НЛО прилетело и опубликовало эту надпись здесь
Задача фреймворка не идеальный код, а дать ядро, на котором можно удобно решать какие-то задачи, например писать сайты. И API фреймворка должно быть хорошо описано.

Код же вообще может быть закрытым, и там могут быть оптимизации кода, которые не с идеальным для чтения кодом рядом не стоят.
НЛО прилетело и опубликовало эту надпись здесь
Идеального кода не бывает, всегда есть реальность, и если твой идеальный код работает медленно, грош ему цена.
Код должен быть читаемый и выполнять свою функцию. И ещё раз повторяю, есть фреймворки с закрытым исходным кодом, даже для php в виде расширения.
НЛО прилетело и опубликовало эту надпись здесь
Это уже оскорбление, осторожнее на поворотах!
Я подозреваю мы говорим о разном
Эх, а мы только курсы по Yii1 затеяли)
Хорошая идея, я бы и для этой версии посмотрел, а то всё хочу освоить Yii, но всё заставить себя не могу.
Вы видео курсы затеяли?
У нас будут как оффлайн, так и онлайн встречи. Но всё же будет приветствовать лично присутствие. Про видео оффлайн встреч пока не определились.
Видео было бы хорошо, хотя бы записи вебинаров, в случае невозможности онлайн встреч.
Так есть уже видео курс по Yii на русском, rutracker.org/forum/viewtopic.php?t=4172581
Успехов в осваивании.
Все эти видеокурсы это, простите меня, стрижка купонов с лохов.
Ну, по Yii2 в любом случае рано затевать курсы. Он ещё поменяется.
Мы это понимаем, поэтому будем 1.1 давать. А сами уже смотреть 2 и помогать по мере возможностей.
Где, когда, по чем? =)
Действительно долгожданно, спасибо)
Огромное спасибо за Query Builder, единственное что мне в кохане нравилось больше чем в yii, это интуитивно понятный билдер, теперь и тут порядок.
джва года…
На самом деле немного больше…
Это ещё даже не альфа, можно предлагать альтернативы с описанием, почему оно лучше.
Договорились
Еще не поздно, фреймворк на стадии активной разработки. Может быть просто нужно это же продублировать на github с примером реализации
Это отличная новость!
image
Пожалуйста ответьте мне на вопрос. Как заставить xdebug отображать проперти заданные через get- set-? Во время отладки это очень сильно напрягает, уже не говоря о том, что порой падает php+xdebug (если навести на любую такую проп).

Watch задавать/смотреть тоже не очень удобно =(
Догадываюсь, что только запатчить XDebug…
Убрали C в начале каждого класса — ура!
Но почему не используются чужие компоненты, а пишутся во всем свои? На пример кеширование полнее в doctrine/cache, а логирование в monolog, есть же куча вещей, которые должен решать фреймворк, например помощь в быстром написании кода на фреймворке, генерация скелета будущего кода… По формам нашел только 1 класс, в общем как-то все странно.
Что значит полнее?
На первый взгляд показалось систем разновидностей кеширования больше. Хотя после подробного просмотра видно, что разница не значительна — как минимум переход с другого фреймворка, или просто проекта, использующего популярную doctrine будет проще. Логирование явно полнее в монологе в смысле количества провайдеров для логиирования, имеющих единый интерфейс, бери и используй.
Да и потом эти компоненты оттестированы и готовы, но зачем-то вы их переписываете, вот и вопрос — зачем?
Наши компоненты, на самом деле, старше Doctrine и Monolog ;)
Так я же не спорю. Верю что doctrine и monolog в чем-то опирались на ваш опыт, или еще как-то связаны.
Но сейчас это мощные независимые компоненты, которые развиваются отдельно, свободные, можно форкнуть и добавлять свои фичи, если проекты загнутся. Но пока все хорошо — почему бы не сосредоточиться на других вещах, мне вот это не ясно)
Можно, конечно. Хотя всё-равно придётся писать обёртки, скрывающие сильно отличающийся стиль кода (не форматирования, а именно кода). Мы решили, что быстрее и лучше будет написать своё. Тем более, это критичные по производительности места и дополнительные слои абстракции не особо в этом плане хороши.
Мне очень понравилось, что вы сделали ArrayAccess, это действительно здорово. Только о какой обертке идет речь? Достаточно же форкнуть и отредактировать CacheProvider, или добавить своих методов, соответсвующих вашему стилю, или я чего-то не понимаю?
А на счет скорости — все это закешируется APC, или другим кешером и думаю не будет особо заметно.
Речь об обёртке, которая используется чтобы не показывать программисту код, API которого прилично отличается по стилю от остального фреймворка.

Да, я знаю, что мы те ещё велосипедисты. Просто некоторые штуки мы можем написать достаточно качественно, чтобы велосипедничать.
Немного сумбурно, вот мои мысли на этот счет:

doctrine очень тяжелая, и вообще это джава-стайл в php. php под это не заточен!
ActiveRecord и doctrine решают задачу по разному.

Doctrine — это тяжелый монстр. Зачем, например, нужен dql? Для того что бы перейти на другую СУБД? Это происходит очень редко, зачем ради такой призрачной гибкости мириться с постоянным оверхедом на обработку строк в доктрине? Более того, те или иные запросы оптимизируются в разных СУБД по разному и если начать их оптимизировать под MySQL, то на PostgreSQL перейти будет гораздо сложнее, да и не нужно скорее всего.

Можно долго спорить что лучше, но решать нужно в зависимости от ситуации. Я уверен, что при желании в yii можно использовать доктрину, но из-за этого нельзя будет использовать некоторые плюшки фреймворка.
Плюшки, кстати, никуда не должны уйти при использовании Doctrine. Надо будет попробовать.
Прочитайте внимательнее то, что я написал. Doctrine это не только обертка над БД в том или ином проявлении, есть отдельные компоненты — кеширование, парсер аннотаций, еще пара компонентов, посмотрите репозиторий doctrine и doctrine/common в частности.
Да, согласен, не совсем по теме ответил.
Если по теме, то почему не лепить собственный велосипед если есть желание? Конкуренция всегда нужна:)
Это же не какой-то коммерческий проект, где изобретение велосипеда может стоить проекту жизни.
И если yii будет разбираться и собираться как симфони, то получится почти тот же симфони. Зачем это нужно?
Возможно я слишком восхищен гибкостью симфони. С другой стороны это дает определенные преимущества, если мне нравится философия yii, но не нужен весь yii, а допустим только та же система кеширования, или компонент БД.
Мне кажется модульность не относится к философии фреймворка, а скорее к его гибкости.
За всё приходится платить. Symfony 2 платит за гибкость очень многословным API.
Гибкость симфони это миф :)

Впрочем, тут нет какой-то прямой взаимосвязи.
Компоненты Симфони никак не связаны с оверхедом фреймворка Symfony2: конфигурацией, бандлами, DIC и прочими фишками. Сами компоненты легковесны и приятны. Используются также в Laravel, Silex, Drupal.
Почему-то мне кажется что доктриной вы пользовались очень мало и большинство ваших утверждений из разряда ОБС. Эти поднадоевшие стереотипы про джава стайл, знание под что php заточен, под что нет — не позволяют оценивать ваше мнение всерьез.

«мириться с постоянным оверхедом на обработку строк в доктрине»
Очевидно вы не в курсе того как работает доктрина. В production окружении, запросы DQL компилируются в обычные SQL запросы и хранятся в APC, и никакого оверхеда при последующий запусках. Да и вообще там почти все кешируется.

Не спорю, использование Doctrine2 налагает некоторый overhead, расходуется больше памяти, процессорного времени, однако, в большинстве случаев это абсолютно допустимо, так как в обмен вы получаете много плюшек :)
Кто нибудь может показать рабочий проект на YII, Все хотел посмотреть но никак возможности не предоставиться… :((
На 1.1? Хотя-бы stay.com/ или 2gis.ru/
Кстати, Yii популярен в Сибири, а точнее, в Красноярске: mira1.ru, tvk6.ru, prokrsk.ru, kraszdrav.ru :)
Почему не используется Composer? Так же после быстрого просмотра Yii2, кажется что это всё тот же Yii1.
Не успели пока. Будет.

Yii2 похож на 1.1 идеями и частично кодом. Делать совершенно другой фреймворк, как Symfony 2 после symfony 1 цели не было.
Тогда это yii 1.2 ;)
Так обратной совместимости я так понимаю нет, из-за отказа от приставки C в классах, или это как-то обошли?
Нету конечно. Про 1.2 — это шутка.
Ну так это даже ещё не альфа. Ожидаемо.
А можно узнать оставите ли вы такую же реализацию компонентов или будет что-то новое.
Просто вся эта реализация через magic методы get/set она крайне хрупкая и да, попахивает черной магией.

Что можете сказать по поводу альтернатив:
* трейты ( уже ж 5.5 почти вышел, пора смело переходить на 5.4)
* прекомпиляция — генерация файла со всеми внутренними свойстами и методами.

Имхо любое из этих решений будет удобнее. Плюсы:

* можно получить чистый стектрейс
* можно всегда перейти к нужному методу
* всегда есть понимание чье это свойство и чей это метод.
* решение ситуаций вызова несуществующих свойств-методов ещё на этапе препроцессинга.
Трейты не подходят. Нам состояние нужно и возможность в рантайме подключать и отключать. Перекомпиляция штука инетерсная, но кроме геттеров и сеттеров ей ничего не решить (behavior, события).

На тему перехода к методу, phpdoc решает проблему. По крайней мере в PhpStorm и netbeans.
Почему же, она решает эти вещи… Ок, события они хороши сами по себе. Их, допстим, трогать не будем :)

Но для behavior — самое оно.
При __call, мы уже не будем в рантайме перебирать все доступные behaviors и не будем искать в них методы, а уже будем обладать готовым списокм доступных методов, которые будут проксироваться в behvaiors.

Ах да, плюсом прекомпиляции как по мне может быть то, что она работает с существующим решением. Допустим, если класс не сблиджен идет фолбек к магическим методам и свойствам.
Да, занятная идея. Надо будет посидеть-подумать…
Оки, добавим в повестку дня нашей встречи на HotCode :)
Тут не поспоришь, да.
Yii::$app — почему?
Кода я посмотрел index.php, мне даже показалось, что будет DI, но потом заглянул в контроллер, и увидел этот ужас. Мало того, что раньше ядро было глобальным, теперь ещё и application является публичным свойством… Я в печали.
А это не DI?
DI передается явно через конструктор или сеттер, а класс со статической глобальной переменной — это все равно что просто глобальная переменная по всему коду.
Ок. Зачем вам тут честный DI?
Да DI не обязательно, но код был бы менее связанным.
Поразила именно глобальная переменная, имхо — это кощунство)
Связанность кода нас в это случае не пугает. Тесты для связанного кода не проблема.
Проблема тут только в том, что идиоты могут юзать эту переменную там где это вообще не нужно. Например, во вьюшках вызывать экшны или делать прочую муть. То есть нужно как-то контролировать доступ к этому свойству (а также к БД).
Муть можно делать и через `mysql_query`. Если хочется изолировать view, лучше использовать какой-нибудь Twig.

Спасибо, кстати, за напоминание, я там прям перед выкатыванием кода сделал app глобальной. Надо сделать это опциональным…
Не нашел реализацию глобальных событий, о которых упоминали Yii2
Выкидывайте их из \Yii::$app, подписывайтесь на них же.
Отделили finder от самих представлений строк из таблиц! :)
$customers = Customer::findBySql('SELECT * FROM tbl_customer')->all();

Раньше выносило мозг — можно было вытаскивать данные так:
$user = User::model()->findByPk(1);
$user2 = $user->findByPk(2);
Да, это была одна из самых главных ошибок AR в 1.1.
В php 5.2 было два вартанта, либо сделать как было, либо явно отделить файндер
В ActiveRecord появились oldAttributes, их так не хватало, я даже всегда расширял ActiveRecord, что бы они там были:)
НЛО прилетело и опубликовало эту надпись здесь
Скорее всего возможно, но цели у нас такой нет.
Очень жаль, в свое время идея безболезненного переезда с Kohana 3 на Yii была отвергнута в связи с жесткой привязкой AR к Yii. Кроме того, я бы не отказался использовать AR в мелких проектах.
Какой странный аргумент. Не переезжать на фреймворк потому что хочется использовать его AR, но чтобы была возможность его отвязать. Реально это не понадобится. В 1.1, если что, нормально можно пользоваться тем же Doctrine, если хочется.
Дело в том, что нет возможности постепенно портировать модели, для переезда придется одновременно портировать контроллеры, все модели и частично шаблоны(хотя для хелперов можно написать обертки).
Ухх как здорово. :) сейчас пойду смотреть.
class Controller extends \yii\base\Controller
Повбывав бы…

yii.php, но при этом YiiBase.php

Я так понимаю PSR-0 тут не выполняется
Что не так с class Controller extends \yii\base\Controller?

yii.php на загружается автозагрузчиком.
Почему пространства имен с маленькой буквы? На вкус и цвет, как говорится, но как по мне, то \Yii\Base\Controller лучше, чем \yii\base\Controller

И вообще, почему Yii — yii.php, но при этом YiiBase — YiiBase.php (как autoloader это отрабатывает?)???

Почему контроллеры в protected находятся в корневом пространстве имен?
Пространства имён с маленькой буквы не противоречат PSR-0 и совпадают с именами директорий.

Автозагрузчик по yii.php не отрабатывает. Он подключается явно в index.php. Переимновать для порядка, в принципе, можно.

В каком пространстве имён должны быть контроллеры в protected?
если судить по моделям в новой версии фреймворка (namespace app\models;)

то, в app\controllers
Я знал, что так будет. Это всё из-за меня — стоило решиться начать основательный проект на Yii и дописать его скелет, как анонсировали Yii2.
Всё правильно начали на 1.1. Двойка ещё очень долго не будет стабильной.
SamDark, А кажется в Yii2 behavior для организации nested sets обещали нативно встроить?
Когда и кто?
Это никак на обещание не тянет :)
Да, про «имеет все шансы стать частью фреймворка» уже не актуально… теперь уже точно станет частью фреймворка с малость переработанным API.

Странно, мне всегда казалось что тянет :)
Ладно, спасибо за фидбек.
А, вот это тянет :) Не туда посмотрел.
С тех пор много всего поменялось. В частности появилась идея, как нормально организовать расширения и сделать некоторые «официально одобренными» без раздувания фреймворка.
Понял, спасибо за информацию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории