На: http://yiiframework.ru/doc/guide/ru/index - документация получше, но там похоже что по 1-му Yii, а не по второму.
Да, почти все материалы на http://yiiframework.ru, кроме форума, касаются Yii1, поскольку Yii2 не так давно релизнулся. Пользуйтесь официальной английской документацией. Ссылки - в предыдущем посте
Так документация пишется не для того что бы научить программировать на пыхе. Она нужна что бы быстро сориентироваться, а затем уже можно посмотреть гайды от местных гуру и API.
Спасибо. Раньше почему-то не встречал. Ну.. я так понял это то же, только в оригинале. class reference это хорошо, с остальным как-то грустно. Добавлено спустя 2 минуты 13 секунд: Для новичка эта документация не очень то удобна. Главное за что мне нравится PHP - по нему, в отличии от Java/C#/C++,- можно без проблем найти хорошую и быстро и легко понятную документацию и справку. Вот официальная по Yii2 как-то не так легка проста и удобна. Yii1 и Yii2 обратно не совместимы?
Совсем разные. Yii1 рассчитан на php 5.2, Yii2 - php 5.4 и выше. И очень много изменений - пространства имён, повсеместное использование Composer, изменения в маршрутизации, в ActiveRecord и т.п. Не знаю, я его быстро освоил по официальной документации. И это повсеместная практика - разделять User Guide и Class Reference. Обычно я смотрю сначала User Guide, потом, если чего-то не нашёл там, перехожу в Class Reference. Я правда с Kohana переходил, так что опыт MVC у меня уже был, и я знал, что искать: как маршруты делаются, как контроллер организовать и т.п.
Между php 4.3 и php 5.6 разница конечно есть, но в целом я не жалею что я сперва читал очень хорошую для новичка документацию по php 4.3, а затем посмотрел информацию по php 5.6. Сейчас смотрю с того сайта документацию по Yii1 - сразу многое понятно становится. p.s. если честно я не знаю чем php 5.6 отличается от php 5.2
Там изменений цела куча - namespace (появились в php 5.3), сокращённая запись массивов (появилась в php 5.4, повсеместно используется в Yii2), трейты (появились в php 5.4, повсеместно используются в yii2), индексирование результата функции напрямую, операция возведения в степень (php 5.6 конкретно) и ещё куча всего.
Ну.. вроде не такие глобальные изменения, умеренные. Буду теперь знать что в 5.2 не было пространств имен и трейтов. Сокращенную запись массивов теперь буду знать что есть такая. Теперь и ** буду знать что означает. Индексирование результата функции напрямую это $var=foo()[$i]; ? Хм.. я думал оно всегда было))).
Не, до php 5.4 не было. Изменений больше, на самом деле. Добавлено спустя 2 минуты 34 секунды: Изменений достаточно, чтоб скрипт, рассчитанный на php 5.4 не запускался на php 5.2, вылетал с ошибкой синтаксиса. Вообще, смысл сейчас учить версию yii1.1, если есть yii2 ? Не знаю, что такого страшного вы нашли в официальном руководстве. Там, в принципе, есть одна ошибка, из замеченных мной, но в целом всё работает как там описано.
Передохну и попробую. Страшного ничего - форма подачи документации грузит мозг, мозг начинает немного побаливать, и ничего не понимает все равно. Сейчас вроде в целом немного понял как чего, должно быть попроще.
Это нормально что код фильтров находится в модели, а не в контроллере? Это нормально что Представление напрямую обращается к Модели? Я вот то руководство смотрю там в примере в представлении пишется: <?= $form->field($model, 'name') ?> - при том представление обращается напрямую к внутреннему полю модели, даже не к методу модели. - а если я захочу поменять поле в формочке - мне поля в классе модели менять?? Это нормально что в глобальном пространстве имен Предстваления появился непонятно откуда объект $model ??? Где тут разделение кода я не пойму - по моему всё в одну кашу. P.S. разбираю вот этот пример: https://github.com/yiisoft/yii2/blob/master/docs/guide-ru/start-forms.md
Код фильтров, находящийся в моделе - вполне нормально, поскольку фильтр - это работа с данными, контроллер не должен сам этим заниматься. Доступ к модели в представлении - вполне нормально, если используется только для получения готовых данных. В любом случае, модель зависима от контроллера, поскольку именно контроллер передаёт ей данные, так что если бы не была передана модель, были бы переданы данные в другом виде. Разделение в том, что представление получило готовые данные, а не само занимается из выковыриванием из базы и обработкой. Ну это поменявшееся поле должен же кто-то обработать, да? Оно же не для красоты поменялось? Модель, Представление и Контроллер - это не три независимых слоя, они взаимосвязаны. Ну и потом, ActiveForm удобная штука, но можно ими и не пользоваться, если не нравится.
Зачем они в MVC фреймворке вообще есть, если не реализуют концепцию отделение отображения от внутренней работы. Прямо в представлении обращаться напрямую к переменной модели - жесть. Сидит себе Yii-верстальщик, редактирует представления, и напрямую в внутренние свойства модели лезет - что можно придумать хуже. - В том примере обработчика почему-то нет. Я вот хочу написать в формочке "Имя", введенные данные передать в функцию в модели getName($name), а она уже проведет обработку имени как ей нравится.
Ну он все равно куда-то лезть будет, да? Ему же нужно данные выводить, а не просто голую вёрстку. К примеру, нужно вывести список товаров - товары в каком-то виде надо передать в представление, чтоб оно с ними работало, да? При подходе ActiveRecord товары - это массив экземпляров модели. Поэтому я и говорю, отображение всегда зависимо от остальных слоёв, независимым оно не бывает. ActiveForm удобны тем, что они автоматически подставляют из модели уже введённое значение, которое надо отредактировать, автоматически выводят сообщение об ошибке, при ошибке автоматически подставляются введённые данные, чтоб пользователь не вводил повторно то, что ввёл правильно, могут автоматически проводить client-side валидацию, вплоть до AJAX-валидации. Видите, сколько работы за вас сделано. Обработка - в следующей главе идёт. Потом, в Yii есть традиция отдельно создавать модели для обработки форм, отдельно - для базы данных. Добавлено спустя 8 минут 57 секунд: Разделение идёт не на три независимых друг от друга части, ещё раз. И контроллер, и представление зависят от модели, от её публичной части. Не должны зависеть от её реализации, да.
Если в Yii - все остальное так же, а вероятно так и есть, то я пока не особо понимаю преимуществ Yii, перед тем, чтобы архитектор системы подумал неделю-две над будущей структурой проекта, и контролировал её соблюдение. Добавлено спустя 39 минут 22 секунды: Это всё прекрасно, только они не сочетаются с концепцией MVC, а потому немного странно что они делают в MVC-фреймворке, если конечно Yii таковым является. Почему не сочетаются: Есть Backend-Developer, он создал модель, и внес в неё стандартные геттеры, сеттеры, а все внутренние свойства сделал приватными. - И вот как к этой модели прикрутить Yii-виджет? Менять модель противоречит концепции MVC. Или верстальщик решил поменять названия полей в представлении. Снова менять модель? Какой это MVC - если на каждый чих верстальщика нужно менять модель??
Опять же, что-то вам поменять всё равно в таком случае придётся. Не модель, так контроллер. Потом, Yii-модели активно используют магию __get, поэтому если в модели есть метод getName(), то будет срабатывать $model->name. Потом, я же говорю, для обработки форм создаётся отдельная модель, такая концепция. А она уже вызывает всё остальное. Установите Advanced-шаблон, и посмотрите, как там регистрация и авторизация сделана. У каждого фреймворка своя специфика, я спорить с вами не буду, а то это надолго. Не нравится Yii, возьмите Zend Framework, Laravel, Symfony, Pixie. Перечислять ещё?
1. Откуда мне знать что в них лучше 2. Я так поглядел, Yii самый популярный в РФ. А я фреймворки изучаю не для работы на себя. Добавлено спустя 22 минуты 9 секунд: Zend Framework и Symfony я сразу отмел как сложные. Смотрел на Yii, Laravel, CodeIgniter. В результате решил что Laravel получше, но его мало кто использует в России. С CodeIgniter не разобрался - что это за вещь, но на западе популярна. А тут чего-то пообещали на Yii на забугорном фрилансе задание дать, потому в его сторону чаша и склонилась.
На Yii форуме после долгих мучений подсказали: 1. Использовать <?= $form->field($model, 'name')->label('Имя') ?> 2. Использовать шаблонизатор. Я вот с шаблонизаторами честно говоря не понял что имелось ввиду. 3. Использовать какие-то магические методы get, set. Не понимаю как они работают, но факт с ними стало все как нужно. Значит не все так плохо с Yii2, просто нужно найти нормальную документацию ,с нормальными материалами, и номральными примерами, где сразу все показано правильно.
Надо сначала php выучить. А то вам что не скажешь о php, вам всё открытие. Документация только одна, и большинству людей её хватает. Есть книжки по Yii2. Вот эта, к примеру, считается одной из лучших, хотя я пока не нашёл время прочитать - мне и так в принципе неплохо программируется. http://www.mini-soft.ru/product/481130. Магические методы - это тоже к основам php относится: https://php.net/manual/ru/language.oop5.magic.php. Их многие фреймворки используют, не только yii. <?= $form->field($model, 'name')->label('Имя') ?> - это вы про что? Ну можно так метку задать, но причины ваших предыдущих возмущений это не отменяет )) Шаблонизаторы - это smarty, twig и прочие. Типа можно их к yii2 прикрутить с помощью всяких расширений. Не пробовал, честно говоря, я их не люблю. Php и сам недурно справляется.
Некоторые люди метод clone даже не используют никогда, а вы ожидаете что новичек в пхп знает магические методы гет и пост. магические методы, плюс метка - вполне решают. Что не знаю магических методов - тут и правда по пхп дырка, а вот что в официальной документации по работе с формами метку не указали - это косяк документации. Та книжка, что вы порекомендовали, помимо того что 1200р стоит (для хорошей книжки так то не дорого, правда нужно поправочку сделать что я нынче живу на меньше чем прожиточный минимум), так еще и размером 450 листов. Мне её месяц читать что ли? Я думаю что то, что я хочу узнать по Yii-framework вполне можно уместить на 50 страницах. Еще 400 в нагрузку я читать не хочу. Если я захочу обложиться книжками, и теорией по самые помидоры, то я лучше Java буду изучать или .Net, а не PHP c Yii фреймворком. Пока что я по самые помидоры влазить не хочу. Как потом сложится - пока не знаю. Пока что смотрю официальную документацию, раз ничего лучше нет. Очень жаль, что то, за что мне так понравился PHP (качество документации и справки на порядок лучше чем в других языках и средах), в Yii-framework реализовано не так хорошо.
Это описано. Просто в другом руководстве. Не нашли что-то в http://www.yiiframework.com/doc-2.0/, ищите в описании API. И не знаю как в русской версии, не читал, а в английской есть про то, как метки задавать и в общем руководстве. Я честно говоря в русскую вообще не заглядываю, когда речь про Yii идёт. Мне не проблема прочитать по английски тоже самое. Люди почему-то думают, что php не нужно изучать - это неправильно, чтоб программировать на нём, нужно также обкладываться теорией по самые помидоры, как и в случае с Java, или C++, или C#. Особенно если учесть, что фреймворки обычно используются в нетривиальных проектах. Для простенького блога хватит и WordPress с бесплатной темой (хотя я делал блог и на Yii, там специфические были задачи). На 50 страницах про фреймворк с 20 МБайт-ным дистрибютивом ну никак не расскажешь.
Подскажите как это работает: Код (PHP): $countries = $query->orderBy('name') ->limit($pagination->limit) ->offset($pagination->offset) ->all(); В объекте $query вызывается метод "orderBy('name')", который создает объект, внутри которого вызывается метод "limit($pagination->limit)", который создает объект, внутри которого вызывается метод "offset($pagination->offset)", который создает объект, внутри которого вызывается метод "all()". Если оно так, то как интересно делается такая система классов?
Если функция возвращает объект, то можно вызывать функцию дальше. Здесь функции возвращают $this, поэтому все обращения идут к одному объекту. Это называется "текучий интерфейс". https://ru.wikipedia.org/wiki/Fluent_interface#PHP Добавлено спустя 21 секунду: А могли просто в исходник Yii заглянуть
Хм.. Спасибо. Посмотрел. Интересно выглядит.)) Я до исходников пока не добрался - азы изучаю. Хотелось бы спросить - как не путаться в коде, когда контроллер вызывает представление, и просто кидает в глобальную область видимости представления все параметры, что тот хотел передать? И находясь внутри представления не очень то понятно что именно кидает в него контроллер. Я бы может как-то в начале кода представления прописывал в комментариях какие параметры должен передать render(). Как там по обычаям?)