Доступно публичное превью Yii 2

    Долгожданное превью не менее долгожданного фреймворка Yii 2 стало доступно для всех желающих.

    Вольный перевод официальной новости:
    «Мы рады сообщить, что превью Yii 2 доступно на Github. Это важное событие в разработке Yii 2, которая началась более двух лет назад — с тех пор мы полностью переписали его.

    Обратите внимание что фреймворк находится в интенсивной разработке и мы можем внести в него серьезные изменения, пожалуйста не используйте его в продакшене.

    Мы искренне приглашаем вас поиграться с кодом Yii 2 и написать о своих впечатлениях нам, а так же приглашаем поучаствовать в его разработке»

    Yii 2 на Github
    Багтрекер Yii 2
    Ветка форума посвященная Yii 2

    Узнать что сделано, что планируется сделать и куда движется фреймворк можно с помощью Roadmap проекта.

    Было бы интересно если кто-то прогнал бы фреймворк по тестам и сравнил бы с тем что есть сейчас на сцене, но у меня уже сейчас есть немного инфы от одного из разработчиков Yii 2, Александра Макарова:



    UPD:
    Интересный факт — фреймворк выбрался в тренды GitHub!

    UPD 2:
    Появился хабра-топик с обзором новой версии фреймворка — Yii2. Знакомство

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 110

      +2
      Не подскажете ссылку на описание особенностей?
        +3
        Прям «рекламного» списка фич на Yii 2, я к сожалению нигде не нашел, но есть вполне проясняющий ситуацию roadmap. Надеюсь это то что вам надо :)
          0
          0
          " Прелестно мой дорогой друг! Прелестно! "
            +4
            Счастье для всех и большими порциями.
            Выглядит хорошо, а вот в Yii 1 страшно было порой в код заглядывать.
              0
              Да ладно? Грешки там конечно есть, но код там довольно хороший;)
                0
                Думаю, страшно от форматирования кода. Это правда.
                  +1
                  Именно, из-за этого код какого-нибудь YiiBase::import абсолютно нечитаемый.
                    –2
                    Ты видимо не видел страшно выглядящий код;)
                      +1
                      В каком из современных популярных фреймворков код страшнее? Хотел бы посмотреть.
                        –2
                        Я не имел ввиду фреймворки конкретно.
                        Но если нужен популярный пример, то можно посмотреть CMS-ки аля джумла или битрикс. При одно взгляде появляются рвотные позывы.

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

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

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

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

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

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

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

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

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

                                                      Не спорю, использование Doctrine2 налагает некоторый overhead, расходуется больше памяти, процессорного времени, однако, в большинстве случаев это абсолютно допустимо, так как в обмен вы получаете много плюшек :)
                                            0
                                            Кто нибудь может показать рабочий проект на YII, Все хотел посмотреть но никак возможности не предоставиться… :((
                                            +2
                                            Почему не используется Composer? Так же после быстрого просмотра Yii2, кажется что это всё тот же Yii1.
                                              +1
                                              Не успели пока. Будет.

                                              Yii2 похож на 1.1 идеями и частично кодом. Делать совершенно другой фреймворк, как Symfony 2 после symfony 1 цели не было.
                                                +1
                                                Тогда это yii 1.2 ;)
                                                  0
                                                  Так обратной совместимости я так понимаю нет, из-за отказа от приставки C в классах, или это как-то обошли?
                                                    0
                                                    Нету конечно. Про 1.2 — это шутка.
                                              0
                                              // make sure string length is limited to avoid DOS attacks $valid = is_string($value) && strlen($value) <= 254
                                              сырой еще. очень.
                                                0
                                                Ну так это даже ещё не альфа. Ожидаемо.
                                                +1
                                                А можно узнать оставите ли вы такую же реализацию компонентов или будет что-то новое.
                                                Просто вся эта реализация через magic методы get/set она крайне хрупкая и да, попахивает черной магией.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                        Only users with full accounts can post comments. Log in, please.