Comments 54
Отличная статья, такие обзоры-апи и надо делать, меньше воды и больше нормального кода ;) Определение связей отлично сделано, вообще AR очень хорошей получилась. Кстати новая ActiveForm тоже отличная) Yii2 это rails on php :D
P.S. slavcopost это slavcodev с гитхаба?)
P.S. slavcopost это slavcodev с гитхаба?)
Да это я.
rails on php это точно. это сейчас две мои любимые технологи: рельсы и yii. ребята, все на yii!))
Если не затруднит, можно пару слов о yii? На основном рускоязычном сайте не написано, в чем же все прелести yii. На Вики и то больше узнал.
Можно от знатаков узнать, что больше всего нравится? Или даже не так… почему он так нравится?
Можно от знатаков узнать, что больше всего нравится? Или даже не так… почему он так нравится?
Я знатоком Yii себя не считаю) Yii он целиком и полностью не такой как другие PHP фреймворки. Те кто юзают там Zend или Symfony обычно смотрят на Yii вот такими вот глазами O_o Мне нравится там все: и архитектура, и виртуальные пути ФС, и ORM (ActiveRecord), и очень чистая реализация MVC, то как там виджеты создаются, как легко подключаются всякие MemCache/CacheLite и т.д. Тут можно долго говорить, надо просто попробовать!)
Чем-то мне этот ActiveRecord напоминает Kohana ORM
Большое спасибо за обзор из первых рук! Столько изменений, что я его уже хочу. Чего стоят одни только переделки связей — коротко и по делу. Кода, правда, больше, но зато он понятный. Кстати, всегда интересовал вопрос — статические методы действительно настолько быстрее методов объектов, чтобы уходить от последних? Есть ли где-нибудь сравнение по ресурсам/скорости 1.13 и 2.0?
Всегда было интересно: кто минусует такие топики?
Ведь и тема свежая, и много примеров с кодом
Ведь и тема свежая, и много примеров с кодом
Дизайнеры, к примеру, которые ждут иконок…
Так есть специально заточенный хаб, как-то глупо ждать иконок в посте о PHP фреймворке. А если мозолит глаза — всегда можно воспользоваться настройками ленты
Очевидно хейтеры Yii.
Магия магией погоняет.
Было засилье инстанцовых методов бизнес логики.
Стало процедурно-статическое раздолье в моделях. Создал статические метод — вызываешь его инстацово, да еще и без поддержки ИДЕ.
Почему разработчики так хотят отделить мух от котлет, но, как мне кажется, у них это получилось плохо?! Почему бы просто не разделить букву М в MVC на две составляющие — данные и сервисные методы: Post и PostQuery. В последний поместить все угодные методы byCreator, removed, piblished и тд.
А в целом команда Yii молодцы :) очень много хороших, на мой взгляд, решений и улучшений.
Было засилье инстанцовых методов бизнес логики.
Стало процедурно-статическое раздолье в моделях. Создал статические метод — вызываешь его инстацово, да еще и без поддержки ИДЕ.
Почему разработчики так хотят отделить мух от котлет, но, как мне кажется, у них это получилось плохо?! Почему бы просто не разделить букву М в MVC на две составляющие — данные и сервисные методы: Post и PostQuery. В последний поместить все угодные методы byCreator, removed, piblished и тд.
А в целом команда Yii молодцы :) очень много хороших, на мой взгляд, решений и улучшений.
Кстати такая картина в symfony, в первой части там была модель Post и сразу PostPeer.
А во второй symfony репозитории для каждой модели можно создать сразу.
А во второй symfony репозитории для каждой модели можно создать сразу.
Почему бы просто не разделить букву М в MVC на две составляющие — данные и сервисные методы: Post и PostQuery
И сейчас не сложно их разделить, и будет автокомплит в ИДЕ работать ( подменить метод ActiveRecord::createQuery создать дополнительный класс, подменить возвращаемый тип у find и findBySql для ИДЕ ):
...
/**
* @method static \app\models\PostActiveQuery find( $q = null )
* @method static \app\models\PostActiveQuery findBySql( $sql, $params = array() )
*/
class Post extends \yii\db\ActiveRecord {
...
/**
* @return PostActiveQuery
*/
public static function createQuery() {
return new PostActiveQuery( array(
'modelClass' => get_called_class(),
) );
}
}
class PostActiveQuery extends ActiveQuery {
/**
* @param $title
* @return PostActiveQuery
*/
public function byTitle( $title ) {
$this->andWhere( 'title = :title', array( 'title' => $title ) );
return $this;
}
}
Можно поинтересоваться, почему выбрано так именовать во фреймворке неймспейсы? \yii\db\ActiveRecord вместо Yii\Db\ActiveRecord?
А можете подсказать в новом ActiveRecord можно делать запросы вида:
В текущем виде AR + CDbCriteria выполнить такой запрос у меня так и не получилось.
P.S. Если вопрос глупый, то прошу прощения, просто начал использовать Yii не так давно и всех тонкостей ещё не знаю.
SELECT ..... FROM (SELECT .... FROM tbl2).....
В текущем виде AR + CDbCriteria выполнить такой запрос у меня так и не получилось.
P.S. Если вопрос глупый, то прошу прощения, просто начал использовать Yii не так давно и всех тонкостей ещё не знаю.
$posts = Post::findBySql('SELECT ..... FROM (SELECT .... FROM tbl2)')->all();
А есть для PHP ORM уровня SQLAlchemy? Что бы в таких случаях не надо было опускаться до SQL? (а то СУБД бывают разные и хотелось бы иметь гарантированную прослойку)
Очень много действительно полезных изменений, спасибо авторам за проделанный труд!
Интересует прогноз команды разработчиков, сколько примерно времени понадобится до стабильной версии yii2?
Интересует прогноз команды разработчиков, сколько примерно времени понадобится до стабильной версии yii2?
Что с поддержкой бутстрапа? Вижу в форме его используют. Какой функционал еще предоставлен? Спасибо.
Пока больше никакого. А что ещё нужно?
Ну полной поддержки не нужно. Мне не нравится как сделано в yii-booster где есть виджет даже на Hero unit. Но в своих проектах часто использую виджет на менюшки (удобна поддержка разделителя и многоуровневость, ну и классы соответствующие). Также удобны табы, бредкрампс, пагинация. Было бы удобно если бы был аналог CGridView.
Благодарю за пост, очень понятно и полезно.
Говорят в продакшн лучше пока не использовать, а есть ли какие сроки, когда можно будет более или менее начать его использовать?
Сам пока плохо знаком с YII, но хочу попробовать на нем написать что нибудь. Хотелось бы конечно начать с YII2, поэтому интересуют примерные сроки стабильных версий.
Как я понял с первой версией YII2 несовместим, получается кучу отличных расширений надо будет подождать пока перепишут под вторую версию?
Говорят в продакшн лучше пока не использовать, а есть ли какие сроки, когда можно будет более или менее начать его использовать?
Сам пока плохо знаком с YII, но хочу попробовать на нем написать что нибудь. Хотелось бы конечно начать с YII2, поэтому интересуют примерные сроки стабильных версий.
Как я понял с первой версией YII2 несовместим, получается кучу отличных расширений надо будет подождать пока перепишут под вторую версию?
Заголовок «Yii2. Знакомство (для знакомых с предметом)» лучше бы подошел. А то читает новичок, радуется, что нашел статью, где узнает с самого начала о предмете, заходит — а там его страшными словами в дрожь вгоняют, притом со знанием дела!
Вот увидел код:
Ранее, как я помню, надо было вводить
Я ошибаюсь или это опечатка?
$query->andWhere('user_id = :userId', array('userId' => $userId));
Ранее, как я помню, надо было вводить
$query->andWhere('user_id = :userId', array(':userId' => $userId));
Я ошибаюсь или это опечатка?
Рискну кармой, но всё же поинтересуюсь.
Ну вот делаем мы, к примеру, некий веб-проект. Дизайн нарисовали и сверстали. Бизнес-логику, если там вообще есть бизнес-логика, написали — хоть на РНР, хоть на С++, хоть на хранимых процедурах SQL — не суть.
Осталось прикрутить веб-морду по сверстанному дизайну.
И вот тут я вижу два варианта.
Если наш проект — это публичный сайт, то мы берем битрикс (джумлу, друпал, что угодно), специально обученный по выбранной CMS админ расставляет галочки в админке и вписывает названия полей в верстку -> через пару дней проект готов.
Если у нас веб-приложение, то класс View на сервере уже входит в стандартную поставку PHP и называется json_encode. Нужно только добавить орм по вкусу и приправить тоником.
А вот кому сейчас может потребоваться Yii (теперь с классом View!)...? Мне действительно интересно.
Ну вот делаем мы, к примеру, некий веб-проект. Дизайн нарисовали и сверстали. Бизнес-логику, если там вообще есть бизнес-логика, написали — хоть на РНР, хоть на С++, хоть на хранимых процедурах SQL — не суть.
Осталось прикрутить веб-морду по сверстанному дизайну.
И вот тут я вижу два варианта.
Если наш проект — это публичный сайт, то мы берем битрикс (джумлу, друпал, что угодно), специально обученный по выбранной CMS админ расставляет галочки в админке и вписывает названия полей в верстку -> через пару дней проект готов.
Если у нас веб-приложение, то класс View на сервере уже входит в стандартную поставку PHP и называется json_encode. Нужно только добавить орм по вкусу и приправить тоником.
А вот кому сейчас может потребоваться Yii (теперь с классом View!)...? Мне действительно интересно.
Тому кому и Pylons,Ruby on Rails, Django требуется… «специально обученный по выбранной CMS админ » это если ваш публичный сайт полностью укладывается в концепцию CMS.
У вас идёт упор на СУБД, а вот есть проекты где основные разработки идут в области шаблонов и фронтенда и тут гораздо удобнее такого рода фреймворки.
У вас идёт упор на СУБД, а вот есть проекты где основные разработки идут в области шаблонов и фронтенда и тут гораздо удобнее такого рода фреймворки.
Тривиальный backend можно в Yii сделать за один рабочий день, так зачем мне CMS на незначительную кастомизацию которой могут уйти недели? Проблема только в том что порог вхождения выше в Yii, и прогера на поддержку сложнее наверное найти если что. Хотя для простеньких контентых сайтов действительно CMS юзать сподручнее
Не являюсь поклонником Yii, потому не пинайте :) Какой смысл в методе populate()? Почему контроллер должен каким-то образом заполнять модель? Намного логичнее выглядит $model->populate($_POST).
Раньше (в Yii первом) так и было: $model->setAttributes($_POST['Model']). Тоже не очень понятно, в чём смысл переноса этого метода в контроллер.
1) А связи охранятся автоматичесик без link?
Сеттер для связей тоже нужно писать самому? Или всегда вызывать link?
Не шибко удобно получается.
2) Dirty attributes есть?
3)
тут можно передать модель сразу в форму? Чтобы не писать $model в каждом тэге.
4) В чем смысл populate, если safe attributes хранятся в модели?
5) Можно ли теперь делать так:
6) Зачем 'echo render;' И вообще явный рендер?
Проще же делать как в зенде, рельсах и т.д. Рендеринг одноименного вью автоматически, а если нужно рендерить что-то другое, то уже вызываем явно.
7) Yii::$app->response->redirect(array('site/index')); — зачем использовать статику? У контроллера же может быть поле request?
Думаю и для тестов так лучше.
$post = Post::find(1);
$comment = new Comment();
$comment->text = 'Yii Framework is cool!';
$post->setComments(array($comment));
$post->save();
Сеттер для связей тоже нужно писать самому? Или всегда вызывать link?
Не шибко удобно получается.
2) Dirty attributes есть?
3)
$form = $this->beginWidget('yii\widgets\ActiveForm', array(
'options' => array('class' => 'form-horizontal')
));
echo $form->field($model, 'username')->textInput();
echo $form->field($model, 'password')->passwordInput();
echo $form->field($model, 'rememberMe')->checkbox();
тут можно передать модель сразу в форму? Чтобы не писать $model в каждом тэге.
4) В чем смысл populate, если safe attributes хранятся в модели?
5) Можно ли теперь делать так:
$post->getComments()->approved()->all();// approved - scope класса Comment
6) Зачем 'echo render;' И вообще явный рендер?
Проще же делать как в зенде, рельсах и т.д. Рендеринг одноименного вью автоматически, а если нужно рендерить что-то другое, то уже вызываем явно.
$this->view->var = 'value'; //zend
$this->var = 'value'; // a-la rails. Переменная var доступна во вью.
7) Yii::$app->response->redirect(array('site/index')); — зачем использовать статику? У контроллера же может быть поле request?
$this->request->redirect(...);
Думаю и для тестов так лучше.
1) Пока нет. creocoder работает над этим.
2) Да.
3) Пока нет. Синтаксис для виджетов ещё будет меняться.
4) Это черновой вариант. Он нам пока не нравится.
5) Да. Если нет — это баг.
6) Неявность в этом случае совсем не нравится. Это одна строчка в контроллере, из который сразу можно понять, какой view рендерится и какие переменные в нём доступны.
7) Может. Подумаем.
2) Да.
3) Пока нет. Синтаксис для виджетов ещё будет меняться.
4) Это черновой вариант. Он нам пока не нравится.
5) Да. Если нет — это баг.
6) Неявность в этом случае совсем не нравится. Это одна строчка в контроллере, из который сразу можно понять, какой view рендерится и какие переменные в нём доступны.
7) Может. Подумаем.
Спасибо за ответ. Насчет populate. В рельсах сейчас практикуется такой гем -https://github.com/rails/strong_parameters. Может заинтересует сам подход? Вообще, хорошая идея вынести safe attributes из модели.
Не в ту ветку отправил… это для samdark
Не в ту ветку отправил… это для samdark
У нас нет такой проблемы изначально, чтобы её решать. По умолчанию массовое присваивание не работает. Нужно как раз сделать whitelist атрибутов в scenarios и rules.
Проблема есть, то что в рельсах называется attr_acсessible, в yii — rules. Идея в том, чтобы вынести эти rules из модели. Модель не должна знать о сценариях ее использования и белом списке. Тогда populate пригодится. Он отсеит то, что мы запретим, в контроллере. При использовании strong_parameters нам просто запрещают присваивать что-либо иное, кроме отфильтрованных данных. Модель становится чище, а безопасность не теряется.
Тут, по-моему, дело вкуса. По мне так приятней определить N сценариев использования в самой модели, а в контроллере указывать только имя сценария.
Спасибо за статью!
Такой вопрос: Будет ли в Yii2 RESTful Server из коробки?
Такой вопрос: Будет ли в Yii2 RESTful Server из коробки?
Sign up to leave a comment.
Yii2. Знакомство