• Поговорим о Yii 2
    0

    Я и не говорил, что yii2-queue фреймворконезависимый. Я говорил, что мы не нашли чего-то, что можно было бы взять за базу.

  • Поговорим о Yii 2
    0

    А вообще почему бы и нет? Если есть свободное время — ждём pull request, который добавит совместимость с интерфейсами queue interop.

  • Поговорим о Yii 2
    0

    Что такое queue-interop? Это? https://github.com/queue-interop/queue-interop с 200 инсталлами и 20 звёздочками?

  • Поговорим о Yii 2
    +2
  • Поговорим о Yii 2
    0

    Палка о двух концах...

  • Поговорим о Yii 2
    +4

    У нас уже есть фичи лучше конкурентов — генерация кода, query builder, AR (если выбирать из реализаций AR, конечно), i18n, RBAC, дата-провайдеры и гриды, active form, phpdoc в коде и дока. Некоторых из этих фич у других просто нет.


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


    Задача 2.1 не добавить тучу киллер-фич а наоборот: ввести больше интерфейсов, чтобы использовать больше качественного стороннего кода, выкинуть часть своего кода и почистить то, что осталось. Это будет уже качественный рывок вперёд потому как набор относительно уникальных фич, которые мы сделали хорошо и ради которых стоит использовать именно Yii, есть.

  • Поговорим о Yii 2
    +1

    Ну, Павел ознакомился с PSR-7 и решил запилить в будущих версиях.

  • Поговорим о Yii 2
    0

    Порциями. Первые порции уже завезли. Остальные продолжают завозиться по мере поступления.

  • Поговорим о Yii 2
    +1

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

  • Поговорим о Yii 2
  • Поговорим о Yii 2
    0
    так теперь этим третьим "чем-то" будет yii2-http-клиент, и в проекте скоро появится что-то четвертое.

    Вообще идея была в том, что будет использоваться что угодно через интерфейс клиента и, тем самым, не будет зависимости на конкретную реализацию.


    Оно, конечно, видно, что сейчас можно просто завязаться на интерфейсы PSR-7 и deprecate-нуть httpclient на версию 2.1. Вероятно, так и сделаем.

  • Поговорим о Yii 2
    –5

    Бывают исключения.

  • Поговорим о Yii 2
    +2

    Так можно разнести практически любой фреймворк. У каждого из них есть недостатки. Какой-то лучше в одном, какой-то в другом. Например, Symfony хорош стабильностью, LTS и позволяет удобно делать абстракцию, но и побуждает новичков делать адовый лазанья-код, который будет похуже спагетти. Laravel офигенно быстро релизит новые фичи, но забивает на поддержку и LTS по-страшному. Проекты приходится постоянно переписывать. Ну и так далее.

  • Поговорим о Yii 2
    0

    У Symfony с этим всё хорошо, согласен.

  • Поговорим о Yii 2
    –1

    Guzzle не устроил интерфейсом. Есть проект. В нём есть зависимости. Одна зависимость использует Guzzle, вторая — httplug, третья ещё что-то. В итоге у нас натягивается много либ. Если зависимости используют httpclient вместо всего этого, появляется возможность вытаскивать одну либу и собирать только её баги.


    p.s. да, PSR-7 сейчас эту проблему решает, но тогда его не было...

  • Поговорим о Yii 2
    0

    Definitive guide не предлагает использовать AR всегда и везде. Наверное, надо добавить ещё больше сносок про то, что это везде и всегда не надо… если есть идеи, куда именно и в какой форме — дайте знать.

  • Поговорим о Yii 2
    +2

    Порог действительно низкий. Это так.


    Вы хотите, чтобы на PHP были либо опытные продвинутые разработчики, либо никого? Я нет потому что тогда сильным проектам, где эти продвинутые разработчики нужны, будет неоткуда вырастать.


    Yii допускает много вольностей. На нём можно быстро фигачить, а можно писать грамотно и хорошо. Зависит от опыта и дисциплины того, кто пишет.

  • Поговорим о Yii 2
    +1

    4 года — это время жизни нормального проекта. Не каждые же пол года ломать всё и релизить мажорную версию...

  • Поговорим о Yii 2
    0

    Можно завести две record на одну таблицу в разных namespace-контекстах.

  • Поговорим о Yii 2
    0

    Из этого ничего :)


    • queue — фреймворконезависимых очередей нормальных не нашлось. Запилили прототип на хакатоне потому что было интересно, сможем ли. Прототип Журавлёв допилили до прекрасного состояния и расширение мы приютили. При этом он его развивает, мы только помогаем советами и докой, как и помогали пока репозиторий был в его аккаунте. Времени не кушает.
    • authclient был с самого начала. Он прилично интегрирован с аутентификацией. Если бы использовали внешнюю либу для OAuth, так и так пришлось бы обёртку делать.
    • collection — сильно просили прямо в фреймворке сделать поддержку. Решили сделать в расширении. Это не просто generic-коллекции, там есть и специфичные для AR Yii штуки, которые позволяют работать с базой довольно эффективно, а не вытягивать всё и фильтровать средствами PHP.
    • httpclient — обёртка с двумя простейшими дефолтными драйверами. Нужна чтобы, например, можно было бы подменить Guzzle на что-то ещё.
    • shell — да, скорее всего так. Но каши не просит, можно и оставить.
  • Поговорим о Yii 2
    +1
    Вам выше уже всё сказали — зачем, к примеру, пилить свой, какой-нибудь к примеру FileSystemHelper, если есть множество готовых, устанавливающихся одной командой composer? А на это тратится безумное количество времени.

    Конкретно FileSystemHelper — только обратная совместимость. Некоторые другие части Yii, которые есть где-то ещё, потому что они получились лучше, чем где-то ещё.


    Ну и плюс тут вопрос контроля и хрупкости. Вспомните left-pad и npm...

  • Поговорим о Yii 2
    0

    Да не, не приходится. Отлично всё конфигурируется либо через контейнер, либо по месту. Просто люди привыкли делать обёртки ещё с 1.1 и по инерции наделали их очень много...

  • Поговорим о Yii 2
    +4
    с обязательным переносом на новый фреймворк через 2-3 года

    А сразу писать нормально или порефакторить потом никак?

  • Поговорим о Yii 2
    0

    Инстанциацию кастомную надо, да. Что-то вроде https://github.com/samdark/hydrator

  • Поговорим о Yii 2
    0

    Нет. Ничего не наследуется от AR. Используется либо AR внутри репозитория, либо вообще не используется. Query Builder тоже неплох.

  • Поговорим о Yii 2
    0

    Я много чего не озвучил: https://github.com/yiisoft/yii2/wiki/Plan-for-next-major-versions Плюс посмотрите issue на 2.1.

  • Поговорим о Yii 2
    +1

    Так и в Yii можно так же. DI контейнер в фреймворке вполне себе универсальный и может настраивать не только классы самого фреймворка.


    Также посмотрите на обилие прослоек, коннекторов и обёрток для независимых библиотек, реализованных в виде extension-пакетов.

  • Поговорим о Yii 2
    0

    Через магический геттер.

  • Поговорим о Yii 2
    0

    Почему не получается? Делайте Model и Repository. Кто мешает?

  • Поговорим о Yii 2
    +2

    Я тоже. Одно дело сам фреймворк — в него компоненты удачные перекочевали из тех времён, когда ничего не было. Плюс некоторые запилили с нуля потому как было время на них и могли сделать хорошо. Итеративно улучшать это всё логично потому как оно не хуже альтернатив. Хотя, конечно, временами некоторые части хочется выкинуть и взять что-то, что их переросло. Но обратная совместимость в 2.0 это сделать не позволяет.


    Совсем другое дело — проекты. Вот в них чем руководствуются, реализуя с нуля всякое, я не уверен...

  • Поговорим о Yii 2
    +2
    То, что для ее поддержки пришлось писать свой автолоадер?

    Нас, кроме алиасов, интересовала ещё и скорость загрузки классов. На момент релиза Yii лодер Composer-а был совсем плох в этом плане. issue на тему loader-а практически не было, работает всё стабильно, каши не просит.


    В итоге теперь мы оперируем и неймспейсами и алиасами. Алиасы для ФС выглядят как вынужденное наследие Yii 1, а не фича.

    Алиасами мы для загрузки классов не оперируем. Как и не оперируем неймспейсами для работы с файловой системой.


    Выделяя модули/расширения Yii-шного приложения в отдельные пакеты, мы на много лет вперед привязываемся к текущей мажорной версии Yii. Либо вынуждены писать максимально абстрагируясь то Yii, что очень непросто.

    Так этот факт не меняется вне зависимости от используемого фреймворка. Писать независимые компоненты сложнее, чем завязанные на другой код.


    Будет интересно услышать от вас планы по развитию фреймворка.

    Эволюционные. Будем облегчать ядро, избавляться от всяких jQuery, выкидывать версии PHP до 7-ки, выкидывать HHVM. Выпиливать части в расширения и независимые библиотеки, которые, по возможности, будут поддерживаться заинтересованными разработчиками. Облегчать дерево наследования и стремиться выпилить его совсем...


    Революции вроде 1.1 → 2.0 не хочется. По крайней мере пока.


    Если не секрет, кто сейчас решает стратегические вопросы?

    Я, Carsten Brandt, Дмитрий Науменко, Климов Павел, Boudewijn Vahrmeijer.

  • Поговорим о Yii 2
    0

    В Yii вы можете навесить валидатор на соответствующий приватному свойству геттер. А вообще валидировать приватные свойства не в конструкторе и не в сеттере несколько странно.

  • Поговорим о Yii 2
    0

    Нет, в Active Record нельзя. Сам паттерн создан для обратного. Доктрина — не Active Record.

  • Поговорим о Yii 2
    0

    Поясните, как вы хотите получить публичный доступ к private?

  • Поговорим о Yii 2
    +1

    Ох, опять ужас придётся копи-пастить:


    global $kernel;
    $assetsManager = $kernel->getContainer()->get('acme_assets.assets_manager');‏

    Но что в Yii это сделать в разы легче — факт.

  • Поговорим о Yii 2
    +20

    Неплохой пост. Частично верный, частично нет. Думаю, стоит немного разобрать.


    Архитектура фреймворка


    Выходит, архитектура закладывалась в 2014 — 3 = 2011-м году. Или раньше?

    Архитектура закладывалась в течение многих лет. Что-то, что показало себя хорошо — перекочевало в немного изменённом виде ещё из Prado, что-то из Yii 1.1, а что-то, что показало себя плохо — было обдумано и разработано с нуля.


    Мысленно вернемся в 2014-й. Ожидание второй версии Yii кажется бесконечно долгим, core-разработчики не называют никаких сроков. Разработка ведется в закрытом от публики репозитории.

    А вот и нет: https://habrahabr.ru/post/178917/


    С первой версии нам достались глобальные константы в коде, свой autoloader, своя хитрая система алиасов для файлов и папок.
    Ооооок. Просто напоминаю, что сейчас идет вторая половина 2017-го.

    • Константы — да. Будем менять их на getenv или что-то подобное.
    • Не понимаю, что плохого в своём полностью PSR-4 совместимом autoloader-е, необходимом для поддержики алиасов и работающем быстрее, чем тот же autoload-ер Composer-а. Если бы он было хуже, тогда нет вопросов — выкинули бы не думая. Напомню, что писался он задолго до релиза Composer. И ещё уточню, что autoload-ер в Yii 2 не имеет ничего общего с autoload-ером Yii 1.1.
    • Что плохого в системе алиасов для путей файловой системы и URL тоже не понимаю.

    Приходя к Yii с других инструментов, вы должны понимать, что здесь весь ваш предыдущий опыт становится нерелевантным.
    Yii — это не просто фреймворк, это попытка сделать свою надстройку над языком.

    Конечно, зависит от опыта, но знакомые, которые писали на Yii проекты и до этого работали с Symfony, Django, RoR, Spring и т.д. сильных проблем не испытывали. Незнакомый код не в счёт. Изучение при использовании нового инструмента всегда занимает какое-то время. Любой фреймворк даёт надстройку над языком. Свой DSL, упрощающий построение проектов. Иначе какой в фреймворке смысл?


    Компоненты, их события, поведения… возможно, они имели смысл в PRADO Framework, где "компонентами" были TButton, TAccordion и все вот это.

    Они и сейчас имеют смысл. Да, иерерхия наследования в Yii далеко не идеальная и мысли по сокращению её есть.


    Среди достоинств Yii часто озвучивают простоту фреймворка. Но это правда только отчасти. Знаете, что происходит, когда вы делаете что-то безобидное вроде $post->title = 'Hello'?
    Вы можете побывать здесь, здесь, здесь, здесь, а также в любом прикрепленном к $post event-у или behavior-у. Это может свести с ума во время отладки.

    Только если кто-то очень сильно постарается в коде приложения и либо нацепляет очень много нетривиальных behavior-ов, либо сделает всё на событиях. Логика properties очень простая, покрытая на 100% тестами и хорошо документированная.


    Не добавляет радости и тот факт, что любой компонент приложения из любого места можно достать через Yii::$app. Эдакий экземпляр приложения и сервис-локатор в одном лице.

    Практически в любом фреймворке можно достать глобально и явно контейнер. Но это не означает, что по-другому писать нельзя (в Yii, например, есть нормальный autowiring) и это не означает, что так надо делать.


    DI-контейнер


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


    Внутри Yii 2 собственный контейнер не используется, а все компоненты лежат в Yii::$app, прямо как в первой версии.

    Используется. Поэтому возможно, например, вот это: http://www.yiiframework.com/doc-2.0/guide-concept-di-container.html#practical-usage


    Вот автовайринга в ядре нет. Потому что во-первых — рефлексия, а во-вторых — при чрезмерном использовании отладка лазанья-кода с ним действительно превращается в ад.


    Active Record


    Единственный минус вытекает из сильной связанности фреймворка — если ваша бизнес-логика оказалась в AR-моделях, то переиспользовать все это добро можно только в рамках проектов на Yii.

    Хотели переиспользовать — нечего было бизнес-логику завязывать на работу с базой… если её запихать, например, в entity из Doctrine, которые вроде отдельные, а вроде и с метаданными в виде тучи аннотаций — лучше не будет. Хотите чистого кода — выделяйте его в отдельный слой. Да, это не просто, но одинаково не просто при использовании чего угодно потому как от фреймворка не зависит.


    Фронтенд


    Для установки Yii 2 вам нужно в принудительном порядке поставить глобально fxp/composer-asset-plugin, для того, чтобы поставить jQuery c помощью composer-а, для того, чтобы установился Yii.

    Со следующего релиза 2.0 уже нет. И долго ждать тоже не нужно. Хотя да, использовать fxp было рисковым предприятием и косяков вылезло много.


    jQuery входит в обязательные зависимости Yii 2.

    Пока да.


    Если знаете, как поставить Yii без возни с ненужными фронтенд-пакетами — пишите в комментариях.

    https://github.com/cebe/assetfree-yii2


    Все остальные компоненты


    Абстракция над HTTP, кеширование, логирование… они есть, и они без проблем выполняют свои задачи.
    Конечно же они самобытные, гвоздями прибитые к Yii, и не имплементируют соответствующие им PSR-ы.

    Уже писал в комментах, но повторю. Во первых, это не совсем так: https://github.com/yiisoft/yii2/wiki/PSR-adoption
    Во-вторых, некоторые PSR ещё не были приняты на момент релиза 2.0 и ломать обратную совместимость сразу после их принятия было ни к чему.


    Будущее Yii


    Код, написанный на PHP, работает везде, а код, написанный на Yii — только на Yii. Вы либо ставите на Yii всё, либо ничего. Это риск для долгосрочного проекта.

    В чём именно риск, поясните.


    Конечно, приложив усилия, можно писать framework-agnostic код и разруливать все через DI-контейнер, но это не поощряется.
    Если вы все-таки решитесь на это, вам прийдется забыть про Yii-вский ActiveRecord или начать писать неприлично толстые прослойки между фреймворком и вашей бизнес-логикой.
    Но это, мягко говоря, неоправданно.

    Не понял, при чём там ссылка на issue, созданный членом команды Yii, где нет ни слова про DI.
    И ещё не понял, почему это я не могу взять, например, независимый Facebook SDK и использовать прекрасно в Yii, внедрив его в конструктор сервиса через autowiring?


    Если вы наследуете какой-либо класс своего приложения от любого другого класса Yii, без Yii вы его работать не заставите, ведь он обязательно наследует Object или Component. Вот.
    Даже если вы вытащите вместе с ним весь ворох родительских классов и реализуемых интерфейсов, это вам не поможет.

    Аргументы из серии "а вдруг мне после трёх лет разработки проекта нужно будет поменять фреймворк" — они про коней и вакуум. Такого быть не должно. Если такое есть, в проекте что-то фатально не так.


    С модными нынче DDD и CQRS/Event Sourcing Yii также вам не помощник. Скорее, даже будет вставлять палки в колеса.

    С DDD tactical вам мало что из современных фреймворков поможет. Палки Yii в колёса не вставляет, если вы знаете, как готовить DDD.


    Команда фреймворка всё пишет сама. Даже VarDumper они написали свой, а не взяли из компонентов Symfony.

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


    Регулярно поддерживать и улучшать столько компонентов — очень непростая задача для небольшой команды. И у этой команды есть два пути.

    Во первых, можно оставить все как сейчас.
    Все компоненты пишем сами. Сильная связанность. Полностью изолированная экосистема фреймворка. Небольшое уютное комьюнити. Медленная деградация.

    Во-вторых, можно все-таки разбить монолитный Yii на независимые от фреймворка компоненты.
    Но тогда это будет уже не Yii с простым и удобным API, а просто еще один набор компонентов, не востребованный вне экосистемы Yii.

    Оба пути ведут в никуда.

    Вот только пути не два и не обязательно пускаться в крайности. Например, можно пойти по пути Laravel — выкинуть всё своё, взять за базу компоненты Symfony, написать к ним обёртки и допы. Часть кода можно выделить в библиотеки. Тот же слой i18n у Yii один из самых мощных, так что за востребованность можно не беспокоиться. Или можно часть кода выделить в расширения и подключить к их поддержке и разработке заинтересованных людей. Это уже сделано с ElasticSearch, Docker и очередями и такой подход показывает себя неплохо.


    PHP 7


    Но если мы хотим использовать тайпхинтинг, все это удобное API превращается в тыкву.

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


    Qiang так и не вернулся


    Самые внимательные заметили отсутствие через пять месяцев. Это означает только одно — даже если "грузовик передет" ещё одного члена core team, фреймворк не умрёт.

  • Поговорим о Yii 2
    0

    К сожалению, с event-driven системами работать приходилось :(

  • Поговорим о Yii 2
    +3

    Неактивные — это entity с репозиторием? Ну, в репозиторий, очевидно, напихать.


    А так, например, можно устроить beforeSave() в той же Doctrine. Не раз видел:


    /**
     * @PrePersist
     */
    public function beforeSave()
    {
        // колбасим
    }
  • Поговорим о Yii 2
    –3

    Почему?

  • Поговорим о Yii 2
    +7

    Принципиальная возможность напихать логику куда угодно есть в каком угодно фреймворке. Это не означает, что её туда необходимо пихать...