Comments 110
Не подскажете ссылку на описание особенностей?
Прям «рекламного» списка фич на Yii 2, я к сожалению нигде не нашел, но есть вполне проясняющий ситуацию roadmap. Надеюсь это то что вам надо :)
" Прелестно мой дорогой друг! Прелестно! "
UFO just landed and posted this here
Да ладно? Грешки там конечно есть, но код там довольно хороший;)
Думаю, страшно от форматирования кода. Это правда.
UFO just landed and posted this here
Ты видимо не видел страшно выглядящий код;)
UFO just landed and posted this here
Я не имел ввиду фреймворки конкретно.
Но если нужен популярный пример, то можно посмотреть CMS-ки аля джумла или битрикс. При одно взгляде появляются рвотные позывы.
YiiBase::import конечно большой и имеет много вложенных конструкций, но в современный реалиях php выглядит ни как не страшно.
Но если нужен популярный пример, то можно посмотреть CMS-ки аля джумла или битрикс. При одно взгляде появляются рвотные позывы.
YiiBase::import конечно большой и имеет много вложенных конструкций, но в современный реалиях php выглядит ни как не страшно.
UFO just landed and posted this here
Задача фреймворка не идеальный код, а дать ядро, на котором можно удобно решать какие-то задачи, например писать сайты. И API фреймворка должно быть хорошо описано.
Код же вообще может быть закрытым, и там могут быть оптимизации кода, которые не с идеальным для чтения кодом рядом не стоят.
Код же вообще может быть закрытым, и там могут быть оптимизации кода, которые не с идеальным для чтения кодом рядом не стоят.
Эх, а мы только курсы по Yii1 затеяли)
Хорошая идея, я бы и для этой версии посмотрел, а то всё хочу освоить Yii, но всё заставить себя не могу.
Вы видео курсы затеяли?
Вы видео курсы затеяли?
У нас будут как оффлайн, так и онлайн встречи. Но всё же будет приветствовать лично присутствие. Про видео оффлайн встреч пока не определились.
Так есть уже видео курс по Yii на русском, rutracker.org/forum/viewtopic.php?t=4172581
Успехов в осваивании.
Успехов в осваивании.
Ну, по Yii2 в любом случае рано затевать курсы. Он ещё поменяется.
Где, когда, по чем? =)
Действительно долгожданно, спасибо)
Огромное спасибо за Query Builder, единственное что мне в кохане нравилось больше чем в yii, это интуитивно понятный билдер, теперь и тут порядок.
Дождались!
джва года…
Отличная новость, жаль только в плане js меня не послушались.
Это отличная новость!
Пожалуйста ответьте мне на вопрос. Как заставить xdebug отображать проперти заданные через get- set-? Во время отладки это очень сильно напрягает, уже не говоря о том, что порой падает php+xdebug (если навести на любую такую проп).
Watch задавать/смотреть тоже не очень удобно =(
Watch задавать/смотреть тоже не очень удобно =(
Убрали C в начале каждого класса — ура!
Но почему не используются чужие компоненты, а пишутся во всем свои? На пример кеширование полнее в doctrine/cache, а логирование в monolog, есть же куча вещей, которые должен решать фреймворк, например помощь в быстром написании кода на фреймворке, генерация скелета будущего кода… По формам нашел только 1 класс, в общем как-то все странно.
Но почему не используются чужие компоненты, а пишутся во всем свои? На пример кеширование полнее в doctrine/cache, а логирование в monolog, есть же куча вещей, которые должен решать фреймворк, например помощь в быстром написании кода на фреймворке, генерация скелета будущего кода… По формам нашел только 1 класс, в общем как-то все странно.
Что значит полнее?
На первый взгляд показалось систем разновидностей кеширования больше. Хотя после подробного просмотра видно, что разница не значительна — как минимум переход с другого фреймворка, или просто проекта, использующего популярную doctrine будет проще. Логирование явно полнее в монологе в смысле количества провайдеров для логиирования, имеющих единый интерфейс, бери и используй.
Да и потом эти компоненты оттестированы и готовы, но зачем-то вы их переписываете, вот и вопрос — зачем?
Да и потом эти компоненты оттестированы и готовы, но зачем-то вы их переписываете, вот и вопрос — зачем?
Наши компоненты, на самом деле, старше Doctrine и Monolog ;)
Так я же не спорю. Верю что doctrine и monolog в чем-то опирались на ваш опыт, или еще как-то связаны.
Но сейчас это мощные независимые компоненты, которые развиваются отдельно, свободные, можно форкнуть и добавлять свои фичи, если проекты загнутся. Но пока все хорошо — почему бы не сосредоточиться на других вещах, мне вот это не ясно)
Но сейчас это мощные независимые компоненты, которые развиваются отдельно, свободные, можно форкнуть и добавлять свои фичи, если проекты загнутся. Но пока все хорошо — почему бы не сосредоточиться на других вещах, мне вот это не ясно)
Можно, конечно. Хотя всё-равно придётся писать обёртки, скрывающие сильно отличающийся стиль кода (не форматирования, а именно кода). Мы решили, что быстрее и лучше будет написать своё. Тем более, это критичные по производительности места и дополнительные слои абстракции не особо в этом плане хороши.
Мне очень понравилось, что вы сделали ArrayAccess, это действительно здорово. Только о какой обертке идет речь? Достаточно же форкнуть и отредактировать CacheProvider, или добавить своих методов, соответсвующих вашему стилю, или я чего-то не понимаю?
А на счет скорости — все это закешируется APC, или другим кешером и думаю не будет особо заметно.
А на счет скорости — все это закешируется APC, или другим кешером и думаю не будет особо заметно.
Немного сумбурно, вот мои мысли на этот счет:
doctrine очень тяжелая, и вообще это джава-стайл в php. php под это не заточен!
ActiveRecord и doctrine решают задачу по разному.
Doctrine — это тяжелый монстр. Зачем, например, нужен dql? Для того что бы перейти на другую СУБД? Это происходит очень редко, зачем ради такой призрачной гибкости мириться с постоянным оверхедом на обработку строк в доктрине? Более того, те или иные запросы оптимизируются в разных СУБД по разному и если начать их оптимизировать под MySQL, то на PostgreSQL перейти будет гораздо сложнее, да и не нужно скорее всего.
Можно долго спорить что лучше, но решать нужно в зависимости от ситуации. Я уверен, что при желании в yii можно использовать доктрину, но из-за этого нельзя будет использовать некоторые плюшки фреймворка.
doctrine очень тяжелая, и вообще это джава-стайл в php. php под это не заточен!
ActiveRecord и doctrine решают задачу по разному.
Doctrine — это тяжелый монстр. Зачем, например, нужен dql? Для того что бы перейти на другую СУБД? Это происходит очень редко, зачем ради такой призрачной гибкости мириться с постоянным оверхедом на обработку строк в доктрине? Более того, те или иные запросы оптимизируются в разных СУБД по разному и если начать их оптимизировать под MySQL, то на PostgreSQL перейти будет гораздо сложнее, да и не нужно скорее всего.
Можно долго спорить что лучше, но решать нужно в зависимости от ситуации. Я уверен, что при желании в yii можно использовать доктрину, но из-за этого нельзя будет использовать некоторые плюшки фреймворка.
Плюшки, кстати, никуда не должны уйти при использовании Doctrine. Надо будет попробовать.
Прочитайте внимательнее то, что я написал. Doctrine это не только обертка над БД в том или ином проявлении, есть отдельные компоненты — кеширование, парсер аннотаций, еще пара компонентов, посмотрите репозиторий doctrine и doctrine/common в частности.
Да, согласен, не совсем по теме ответил.
Если по теме, то почему не лепить собственный велосипед если есть желание? Конкуренция всегда нужна:)
Это же не какой-то коммерческий проект, где изобретение велосипеда может стоить проекту жизни.
И если yii будет разбираться и собираться как симфони, то получится почти тот же симфони. Зачем это нужно?
Если по теме, то почему не лепить собственный велосипед если есть желание? Конкуренция всегда нужна:)
Это же не какой-то коммерческий проект, где изобретение велосипеда может стоить проекту жизни.
И если yii будет разбираться и собираться как симфони, то получится почти тот же симфони. Зачем это нужно?
Возможно я слишком восхищен гибкостью симфони. С другой стороны это дает определенные преимущества, если мне нравится философия yii, но не нужен весь yii, а допустим только та же система кеширования, или компонент БД.
Мне кажется модульность не относится к философии фреймворка, а скорее к его гибкости.
Мне кажется модульность не относится к философии фреймворка, а скорее к его гибкости.
Почему-то мне кажется что доктриной вы пользовались очень мало и большинство ваших утверждений из разряда ОБС. Эти поднадоевшие стереотипы про джава стайл, знание под что php заточен, под что нет — не позволяют оценивать ваше мнение всерьез.
«мириться с постоянным оверхедом на обработку строк в доктрине»
Очевидно вы не в курсе того как работает доктрина. В production окружении, запросы DQL компилируются в обычные SQL запросы и хранятся в APC, и никакого оверхеда при последующий запусках. Да и вообще там почти все кешируется.
Не спорю, использование Doctrine2 налагает некоторый overhead, расходуется больше памяти, процессорного времени, однако, в большинстве случаев это абсолютно допустимо, так как в обмен вы получаете много плюшек :)
«мириться с постоянным оверхедом на обработку строк в доктрине»
Очевидно вы не в курсе того как работает доктрина. В production окружении, запросы DQL компилируются в обычные SQL запросы и хранятся в APC, и никакого оверхеда при последующий запусках. Да и вообще там почти все кешируется.
Не спорю, использование Doctrine2 налагает некоторый overhead, расходуется больше памяти, процессорного времени, однако, в большинстве случаев это абсолютно допустимо, так как в обмен вы получаете много плюшек :)
Кто нибудь может показать рабочий проект на YII, Все хотел посмотреть но никак возможности не предоставиться… :((
Кстати, Yii популярен в Сибири, а точнее, в Красноярске: mira1.ru, tvk6.ru, prokrsk.ru, kraszdrav.ru :)
Почему не используется Composer? Так же после быстрого просмотра Yii2, кажется что это всё тот же Yii1.
// make sure string length is limited to avoid DOS attacks
$valid = is_string($value) && strlen($value) <= 254сырой еще. очень.
А можно узнать оставите ли вы такую же реализацию компонентов или будет что-то новое.
Просто вся эта реализация через magic методы get/set она крайне хрупкая и да, попахивает черной магией.
Что можете сказать по поводу альтернатив:
* трейты ( уже ж 5.5 почти вышел, пора смело переходить на 5.4)
* прекомпиляция — генерация файла со всеми внутренними свойстами и методами.
Имхо любое из этих решений будет удобнее. Плюсы:
* можно получить чистый стектрейс
* можно всегда перейти к нужному методу
* всегда есть понимание чье это свойство и чей это метод.
* решение ситуаций вызова несуществующих свойств-методов ещё на этапе препроцессинга.
Просто вся эта реализация через magic методы get/set она крайне хрупкая и да, попахивает черной магией.
Что можете сказать по поводу альтернатив:
* трейты ( уже ж 5.5 почти вышел, пора смело переходить на 5.4)
* прекомпиляция — генерация файла со всеми внутренними свойстами и методами.
Имхо любое из этих решений будет удобнее. Плюсы:
* можно получить чистый стектрейс
* можно всегда перейти к нужному методу
* всегда есть понимание чье это свойство и чей это метод.
* решение ситуаций вызова несуществующих свойств-методов ещё на этапе препроцессинга.
Трейты не подходят. Нам состояние нужно и возможность в рантайме подключать и отключать. Перекомпиляция штука инетерсная, но кроме геттеров и сеттеров ей ничего не решить (behavior, события).
На тему перехода к методу, phpdoc решает проблему. По крайней мере в PhpStorm и netbeans.
На тему перехода к методу, phpdoc решает проблему. По крайней мере в PhpStorm и netbeans.
Почему же, она решает эти вещи… Ок, события они хороши сами по себе. Их, допстим, трогать не будем :)
Но для behavior — самое оно.
При __call, мы уже не будем в рантайме перебирать все доступные behaviors и не будем искать в них методы, а уже будем обладать готовым списокм доступных методов, которые будут проксироваться в behvaiors.
Ах да, плюсом прекомпиляции как по мне может быть то, что она работает с существующим решением. Допустим, если класс не сблиджен идет фолбек к магическим методам и свойствам.
Но для behavior — самое оно.
При __call, мы уже не будем в рантайме перебирать все доступные behaviors и не будем искать в них методы, а уже будем обладать готовым списокм доступных методов, которые будут проксироваться в behvaiors.
Ах да, плюсом прекомпиляции как по мне может быть то, что она работает с существующим решением. Допустим, если класс не сблиджен идет фолбек к магическим методам и свойствам.
К списку плюсов добавлю решение это проблемы, описанной выше: habrahabr.ru/post/178681/#comment_6201835
Yii::$app — почему?
Кода я посмотрел index.php, мне даже показалось, что будет DI, но потом заглянул в контроллер, и увидел этот ужас. Мало того, что раньше ядро было глобальным, теперь ещё и application является публичным свойством… Я в печали.
Кода я посмотрел index.php, мне даже показалось, что будет DI, но потом заглянул в контроллер, и увидел этот ужас. Мало того, что раньше ядро было глобальным, теперь ещё и application является публичным свойством… Я в печали.
А это не DI?
DI передается явно через конструктор или сеттер, а класс со статической глобальной переменной — это все равно что просто глобальная переменная по всему коду.
Ок. Зачем вам тут честный DI?
Да DI не обязательно, но код был бы менее связанным.
Поразила именно глобальная переменная, имхо — это кощунство)
Поразила именно глобальная переменная, имхо — это кощунство)
Проблема тут только в том, что идиоты могут юзать эту переменную там где это вообще не нужно. Например, во вьюшках вызывать экшны или делать прочую муть. То есть нужно как-то контролировать доступ к этому свойству (а также к БД).
Не нашел реализацию глобальных событий, о которых упоминали Yii2
Отделили finder от самих представлений строк из таблиц! :)
$customers = Customer::findBySql('SELECT * FROM tbl_customer')->all();
Раньше выносило мозг — можно было вытаскивать данные так:
$user = User::model()->findByPk(1);
$user2 = $user->findByPk(2);
$customers = Customer::findBySql('SELECT * FROM tbl_customer')->all();
Раньше выносило мозг — можно было вытаскивать данные так:
$user = User::model()->findByPk(1);
$user2 = $user->findByPk(2);
В ActiveRecord появились oldAttributes, их так не хватало, я даже всегда расширял ActiveRecord, что бы они там были:)
UFO just landed and posted this here
Скорее всего возможно, но цели у нас такой нет.
Очень жаль, в свое время идея безболезненного переезда с Kohana 3 на Yii была отвергнута в связи с жесткой привязкой AR к Yii. Кроме того, я бы не отказался использовать AR в мелких проектах.
Ухх как здорово. :) сейчас пойду смотреть.
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 находятся в корневом пространстве имен?
И вообще, почему Yii — yii.php, но при этом YiiBase — YiiBase.php (как autoloader это отрабатывает?)???
Почему контроллеры в protected находятся в корневом пространстве имен?
Я знал, что так будет. Это всё из-за меня — стоило решиться начать основательный проект на Yii и дописать его скелет, как анонсировали Yii2.
Уже готово первое поведение для Yii 2: github.com/creocoder/nested-set-behavior-2
SamDark, А кажется в Yii2 behavior для организации nested sets обещали нативно встроить?
Sign up to leave a comment.
Доступно публичное превью Yii 2