Pull to refresh
393
0
Александр Макаров @SamDark

PHP, Yii

Send message

Занятная реализация, но идея, к сожалению, вредная. Вы поощряете так охранительное поведение, которое подкрепляет важность тревоги. При этом экспозицией и вариациями КПТ с огромной вероятностью (под 70%) можно тревогу снизить почти в ноль.

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

Bootstrap вот: https://github.com/yiisoft/yii-bootstrap5. Для react и других фрейморков: https://github.com/yiisoft/assets

Спасибо.

  1. Переводы атрибутов тоже есть?

  2. У меня обратный опыт. Сначала валидируется фронт чтобы бэк не грузить. Потом бэк. А что за бандлы? Очень интересно глянуть, как это решено.

  3. https://github.com/yiisoft/validator/blob/master/docs/guide/en/result.md#errors

Посмотрел. Да, хороший компонент. По фичам почти сходные.

Отличия валидатора Yii от Symfony Validator:

  1. Есть контекст у валидатора поля. То есть можно легко валидировать, например, "повторить пароль" или валидировать город по указанной стране.

  2. Перевод сообщений из коробки, в том числе имён атрибутов.

  3. Экспорт правил в виде массивов для frontend / CMF.

  4. Удобные способы получать сообщения об ошибках в разных форматах.

  5. Стиль именования.

  6. Код несколько проще.

  7. Не понял, как у Symfony validator посмотреть покрытие тестами. Но вроде их там не мало. У нас 100% + 100% MSI.

Чего нет:

  1. Возможности задать уровень ошибки, https://symfony.com/doc/current/validation/severity.html

  2. Специфичных конкретных правил валидации (но это добавить проще некуда, к тому же https://github.com/yiisoft/validator/blob/master/docs/guide/en/extensions.md#wrapper-for-symfony-rules).

Надо посмотреть, что там в Symfony Validator чтобы нормально сравнить...

Смотря какие требования у проекта. Большая часть пакетов Yii3 уже стабильна, но некоторые ещё нет. Если у вас наберётся много тех, что нет, то у вас два выхода:

  1. Ждать. Так делает большинство.

  2. Использовать для них dev-master или фиксануться на определённой версии и иногда чинить. Так многие делают в нашем чатике в телеграме.

С момента запуска в Docker официально никогда не было графического интерфейса.

Да ну?

Необоснованно я никогда ни на кого не набрасывался. Минусы того же Laravel подсвечивал, плюсы тоже подсвечивал и каждый раз обосновывал и показывал примеры. Фрейворка-идеала нет и не будет — что Laravel, что Symfony, что Yii — все разные и у всех есть и сильные и слабые стороны.

Не позволяет :(

Есть альтернативы?

Я думал что только @roxblnfk такое по нраву. Мы рассматривали это для Yii3, но всё-же решили что пойдём по классике с require.

Я так понял, посыл в том, чтобы не выдумывать своё, а всем сделать открытых штук типа https://imgproxy.net/ или https://www.yiiframework.com/ вложившись туда вскладчину и тем самым повысив и стабильность платформы, на которой выстроено несколько компаний и ещё и сэкономить прилично.

Уточню: Siemens Business Services. Было когда-то такое подразделение, которое занималось проектами не под сам Siemens. Уже не существует.

Так проблема не в том, что проекты одноразовые. Да, очень древних проектов на «галерах» хватает. Проблема в том, сколько на этих проектах вы. И это уже типично не более двух лет. Далее уходите на другой проект и так далее.

Информация из опыта и от коллег. В IT плюс-минус 18 лет. Галеры 1 год (Siemens) и 6 лет (Murano). У коллег в галерах, пожалуй, побольше.

Что некоторые основные проекты сохраняют я знаю, но я не зря упоминал ротацию. Я за 6 лет поработал на 5 проектах с тремя разными стеками. Это круто для роста вширь, но той же архитектуре я там не научился.

Для роста вширь это прекрасно. Согласен.

  1. https://github.com/yiisoft/docs/blob/master/001-yii-values.md

  2. Хотим сделать инструмент чтобы можно было стартовать быстро (gii в работе, документация хорошая тоже). Вход, скорее всего, будет сложнее, чем в Yii2, но мы это сгладим хорошей докой.

  3. С очень малой связанностью (DI по полной), чтобы при росте не ломалось, чтобы можно было любую архитектуру запилить, будь то классический MVC или вертикальные слайсы и нарезка по контекстам.

  4. Чтобы тестить было приятно.

  5. Фреймворк компонентный и как можно менее закрытый от PHP сообщества.

  6. Чтобы сам фреймворк был сверх-стабилен. У нас покрытие практически 100% с очень высоким MSI и полной статической типизацией через Psalm.

  7. Чтобы дебажить было максимально приятно: debug-панелька, максимально понятные ошибки, как можно меньше кеширования и пре-компиляции чтобы XDebug-ом по своему коду ходить, а не по чему-то сгенерированному.

  8. Чтобы конфижить было удобно и, в то же время, гибко.

  9. Как можно меньше магии. Пока держимся под натиском "а давайте final уберём", "а давайте без private по дефолту", "а где мой Yii::$app?".

Да, так бывает, но это менее типично. Обычно большинство проектов «галер» — до трёх лет. Плюс есть ротация, людей перекидывают с проекта на проект по необходимости и в зависимости от платёжеспособности и потребностей клиента на данный момент.

Information

Rating
Does not participate
Location
Воронеж, Воронежская обл., Россия
Works in
Date of birth
Registered
Activity