Comments 42
Отлично! Очень радует формат миграций и исключения в ассетах, а то костыль писать приходилось.
А почему бы миграции не сделать двухнаправленные? Чтобы можно было в up() писать createTable, а down() автоматически понимал что созданную таблицу нужно удалить. У нас обычно в миграциях что-то создается, добавляется или меняется. В остальных случаях можно кидать исключение, мол не могу автоматически сгенерировать down() метод.
Или может быть есть уже такое? Кто подскажет?
А почему бы миграции не сделать двухнаправленные? Чтобы можно было в up() писать createTable, а down() автоматически понимал что созданную таблицу нужно удалить. У нас обычно в миграциях что-то создается, добавляется или меняется. В остальных случаях можно кидать исключение, мол не могу автоматически сгенерировать down() метод.
Или может быть есть уже такое? Кто подскажет?
Есть issue на эту тему github.com/yiisoft/yii2/issues/7928
Cоздавал подобный issue github.com/yiisoft/yii2/issues/7928 с ссылкой все на тот же phinx.org Но тогда он не получил поддержки. Хотя идею эту я реализовал на одном из проектов и остался ей полностьью доволен. Особенно помогает при старте проекта когда 90% миграции добавляют сущность.
Ну, не то чтобы не получил… issue открыт, плюсики есть. Как-нибудь запилим.
Опечатался в первом комментарии, имел в виду вот этот github.com/yiisoft/yii2/issues/593
Формат миграций стал прям супер-супер, вот только возможность добавить комментарий (как-то так бы ->comment('комментарий')) не реализовали, интересно почему?
Не успели.
pull request тебе в помощь :)
github.com/yiisoft/yii2/pull/9089
этот? :)
этот? :)
Парни из core team (@samdark и @cebe) скромно скрыли свой вклад в новые миграции)
SamDark, а как релизятся зависимые проекты?
Я конечно рад, кто есть такой фрэймворк, но я считаю что он УБОГИЙ. За столько лет так и не смогли добавить нормальные виджеты для работы с временем, датой, датой и временем.
Сможете более развёрнуто расписать? Что для вас «нормальные виджеты для работы с временем, датой, датой и временем» и чем не устраивают те, что уже есть?
Легко, скачайте последнюю базовую версию Yii2+ установите и попробуйте через слой вывести input-виджеты время, дата, время и дата. Там только есть дата виджет и все станет ясно.
через слой? Что есть слой?
В симфони вообще нет виджетов, а убогим его трудно назвать.
Да и виджеты времени — это обертки над сторонними виджетами, пишущимися за 10 минут. Так что такой аргумент в пользу убогости явно необъективен.
В симфони вообще нет виджетов, а убогим его трудно назвать.
Да и виджеты времени — это обертки над сторонними виджетами, пишущимися за 10 минут. Так что такой аргумент в пользу убогости явно необъективен.
github.com/2amigos/yii2-date-time-picker-widget вам в помощь. Причём только тут фреймворк?
А зачем мне фрэймворк в котором надо искать, перебирать и мострячить компонент который ОБЯЗАН быть в стандартной комплектации.
Вот пример:
— Не давно попросили сервис создать на Yii так я сервис писал 3 часа, а компоненты времени искал, перебирал и тестил 13 часов.
Зачем такой фреймворк. Одна из задач при создании фреймворка — это экономия времени, если Yii не экономит время вывод один — он убог. Зачем писать фреймворк где виджеты урезаны и нужно использовать сторонние? Ну сделали бы тогда без виджетов вообще или сделайте все базовые — почему надо не туда не сюда, как дороги в России, вроде есть, а вроде нет.
Вот пример:
— Не давно попросили сервис создать на Yii так я сервис писал 3 часа, а компоненты времени искал, перебирал и тестил 13 часов.
Зачем такой фреймворк. Одна из задач при создании фреймворка — это экономия времени, если Yii не экономит время вывод один — он убог. Зачем писать фреймворк где виджеты урезаны и нужно использовать сторонние? Ну сделали бы тогда без виджетов вообще или сделайте все базовые — почему надо не туда не сюда, как дороги в России, вроде есть, а вроде нет.
Это вы еще Ларавел не юзали…
Нужен RBAC — выбирай из восьми кастомных.
Шаблонизатор? Есть два встроенных, но большинство юзают твиг…
Хочешь собственный класс правил для урлменеджера? Придется писать не только рулсы но и сам урлменеджер. Ну и что, что ядро не умеет кастомные вещи, зато его просто переопределять. В юии есть из коробки? Так это потому что он кривой…
И так во всём. Во всём-всём… Как линунс времен 90-х.
У меня у самого много претензий к Юии, много чего не хватает, но цепляться к неполному набору виджетов в ядре? гм…
Нужен RBAC — выбирай из восьми кастомных.
Шаблонизатор? Есть два встроенных, но большинство юзают твиг…
Хочешь собственный класс правил для урлменеджера? Придется писать не только рулсы но и сам урлменеджер. Ну и что, что ядро не умеет кастомные вещи, зато его просто переопределять. В юии есть из коробки? Так это потому что он кривой…
И так во всём. Во всём-всём… Как линунс времен 90-х.
У меня у самого много претензий к Юии, много чего не хватает, но цепляться к неполному набору виджетов в ядре? гм…
начнем с того, что в стандартной комплектации наоборот не должно быть и тех виджетов, которые там есть сейчас. Это реверанс в сторону начинающих программистов, собственно из-за которых фреймворк так и популярен (также как и Ларавел).
Фреймворк должен решать более низкоуровневые потребности, чем удобный ввод даты в UI. А из вашего высказывания понятно, что вы путаете фреймворк с cms. На фреймворке программируют, а не собирают проект из плагинов.
Фреймворк должен решать более низкоуровневые потребности, чем удобный ввод даты в UI. А из вашего высказывания понятно, что вы путаете фреймворк с cms. На фреймворке программируют, а не собирают проект из плагинов.
Я полностью с Вами согласен. Но если бы не было этих виджетов я вообще никогда бы в Yii не полез.
«Фреймворк должен решать более низкоуровневые потребности, чем удобный ввод даты в UI» — спорный вопрос.
«Фреймворк должен решать более низкоуровневые потребности, чем удобный ввод даты в UI» — спорный вопрос.
Вообще, лучше, чтобы фреймворком предлагались не только инструменты, но и какой-то вариант реализации (дополнительными приложениями, а не в ядре — идеально), и набором best practices.
Иначе слишком много приходится строгать.
Это проходил на собственном опыте при разработе на ZF1. Все можно сделать, но все нужно делать. В результате каждый делал по своему и ни о какой «питательной среде» не было и речи — результат — неплохой фреймворк фактически похоронен.
Фреймворк нужен для разработки проектов, а не разработки инструментов.
Поэтому и RoR настолько популярен. Этим и нравится Yii2.
Иначе слишком много приходится строгать.
Это проходил на собственном опыте при разработе на ZF1. Все можно сделать, но все нужно делать. В результате каждый делал по своему и ни о какой «питательной среде» не было и речи — результат — неплохой фреймворк фактически похоронен.
Фреймворк нужен для разработки проектов, а не разработки инструментов.
Поэтому и RoR настолько популярен. Этим и нравится Yii2.
Так есть же
yii\jui\DatePicker. Чем не оно?работает только с датой, а с временем нет и дата-время тоже нет — это огорчает. Мне иногда надо сбацать быстро прототипный проект с базовым дизайном и когда касается работы со временем — начинается проблема.
JQueryUI, с учетом его распространенности, можно считать промышленным стандартом, и для него сделали расширение yii2-jui c полным набором виджетов. Но там никогда не было контрола для совмещенного ввода даты и времени. За то на стороне появился целый зоопарк таких плагинов. Странно ожидать официальной поддержки на все это многообразие.
Выберите любой, который лучше всего подходит для ваших проектов, и сделайте свою обертку. Это не сложно, и много времени не займет.
Или попробуйте github.com/zhuravljov/yii2-datetime-widgets. Делал для своего проекта когда в интерфейсе понадобился ввод даты-времени и временных интервалов.
Выберите любой, который лучше всего подходит для ваших проектов, и сделайте свою обертку. Это не сложно, и много времени не займет.
Или попробуйте github.com/zhuravljov/yii2-datetime-widgets. Делал для своего проекта когда в интерфейсе понадобился ввод даты-времени и временных интервалов.
Но сделать один среднечковый-стандартный виджет времени и включить его в базовую комплектацию — это не сильная проблема. А вот потратить день на перебор зоопарка и найти рабочий пример — это потеря времени.
Если бы я всегда работал с Yii то у меня был бы отсеян этот зоопарк компонент и я знал какие лучше, а какие нет. Но я с Yii работаю редко, раз в пол года и каждые пол года приходиться тратить время на поиск примитивного рабочего компонента.
Я понимаю в чем проблема Yii и могу решить ее сам, данный разговор я затеял не ради себя, в последнее время я использую свой фрэймворк на MVC модели Javascript+php / node Просто новички которые сталкиваются с Yii упарываются в эту же проблему со временем/датой. Мое мнение, или не включать тогда компоненты в фрэймворк или делать все базовые с возможностью установки внешних, а в данном случае разработчики остановились на середине.
Yii мне нравиться как сделан, удобно и понятно, с ним приятно работать. Я его не использую в коммерческих проектах, но делаю на нем демки-прототипы.
PS: Я нашел компонент который хотел, не надо мне давать ссылки.
Если бы я всегда работал с Yii то у меня был бы отсеян этот зоопарк компонент и я знал какие лучше, а какие нет. Но я с Yii работаю редко, раз в пол года и каждые пол года приходиться тратить время на поиск примитивного рабочего компонента.
Я понимаю в чем проблема Yii и могу решить ее сам, данный разговор я затеял не ради себя, в последнее время я использую свой фрэймворк на MVC модели Javascript+php / node Просто новички которые сталкиваются с Yii упарываются в эту же проблему со временем/датой. Мое мнение, или не включать тогда компоненты в фрэймворк или делать все базовые с возможностью установки внешних, а в данном случае разработчики остановились на середине.
Yii мне нравиться как сделан, удобно и понятно, с ним приятно работать. Я его не использую в коммерческих проектах, но делаю на нем демки-прототипы.
PS: Я нашел компонент который хотел, не надо мне давать ссылки.
Вот уж убогим Yii2 никак назвать нельзя. И очень радует направление развития. Разработчикам огромное спасибо.
Так вот находятся люди, которые еще и ругают бесплатный, открытый продукт.
Если вам чего-то во фреймворке не хватает — ну сделайте хоть что-то сами и отправьте пулл реквест — будете и сами пользоваться, и все вам скажут спасибо.
После перехода с ZF1 (для которого писали сами и миграции, и кучу логики, и кучу компонент) в Yii2 пока не удается сделать ничего нового (даже обидно) — все уже есть или в коробке или в расширениях и работает на удивление хорошо.
Так вот находятся люди, которые еще и ругают бесплатный, открытый продукт.
Если вам чего-то во фреймворке не хватает — ну сделайте хоть что-то сами и отправьте пулл реквест — будете и сами пользоваться, и все вам скажут спасибо.
После перехода с ZF1 (для которого писали сами и миграции, и кучу логики, и кучу компонент) в Yii2 пока не удается сделать ничего нового (даже обидно) — все уже есть или в коробке или в расширениях и работает на удивление хорошо.
«Если вам чего-то во фреймворке не хватает — ну сделайте хоть что-то сами и отправьте пулл реквест» — я нашел вариант получше — написал свой фрэймворк. Я указал на незначительную проблему Yii, об которую КАЖДЫЙ «ломает зубы».
Если продукт бесплатный — что у него не может быть проблем о которых стоит тут написать?
Если продукт бесплатный — что у него не может быть проблем о которых стоит тут написать?
Ну, далеко не каждый. Далеко не всем нужны виджеты для времени и не для всех проблема выбрать из 5—6 вариантов. Но вообще про проблемы писать однозначно надо. И за это вам спасибо.
Выбирать из 5-6 вариантов СИСТЕМНЫХ вещей это сакс. Выбирать из 5-6 вариантов простенького виджета который всегда можно переписать самому в случае проблем — элементарно.
С другой стороны при росте проекта оказывается что ты таких расширений поставил штук 18, они частично дублируют друг-друга, у каждого свой стиль, разные решения каких-то моментов, и разные отступления от бестпрактикс…
И тут уже стоишь перед выбором о том, чтобы рефакторить всё, чтобы упорядочить зоопарк, или поддерживать зоопарк…
В идеале конечно было бы иметь некую сертификацию расширений, чтобы были расширения с пометкой «рекомендуемое официально», но это уже фантастика :)
С другой стороны при росте проекта оказывается что ты таких расширений поставил штук 18, они частично дублируют друг-друга, у каждого свой стиль, разные решения каких-то моментов, и разные отступления от бестпрактикс…
И тут уже стоишь перед выбором о том, чтобы рефакторить всё, чтобы упорядочить зоопарк, или поддерживать зоопарк…
В идеале конечно было бы иметь некую сертификацию расширений, чтобы были расширения с пометкой «рекомендуемое официально», но это уже фантастика :)
Это не фантастика, а планы ;)
Это было бы очень приятно.
оффтоп: скажите, я правильно понимаю, что в двойке нет возможности как в первом получить информацию о связях модели по типу public function relations()?
К примеру у меня в 1.1 было расширение которое по наличию связи с User (при условии что таковая связь одна) создавала *Own действия в RBAC для CRUD.
Ну или к примеру хочется сделать для gii генератор миграций по готовой модели. Можно было бы брать правила валидации и связи, что давало неплохой набор для бутстрапинга миграции. Сейчас связи отпадают…
Ну или еще применение, от которого я не готов отказаться, так что для части своих моделей я таки вернусь к старому синтаксису переопределив магию — хочу сделать в своем приложении генератор запросов по аналогии с 1с-построителем запросов, т.е. GUI-формочку в которой есть все уместные для этой задачи модельки, их свойства, связи, и тыкая мышкой можно настроить запрос с простейшими join, unit sum условиями и т.п.
От идеи смотреть на внешние ключи схемы базы отказался потому что кое-кто из упомянутых тут ребят очень долго распевал мне о том как удобно в юии2 работать со связыми между моделями из разных СУБД и всё такое… :)
оффтоп: скажите, я правильно понимаю, что в двойке нет возможности как в первом получить информацию о связях модели по типу public function relations()?
К примеру у меня в 1.1 было расширение которое по наличию связи с User (при условии что таковая связь одна) создавала *Own действия в RBAC для CRUD.
Ну или к примеру хочется сделать для gii генератор миграций по готовой модели. Можно было бы брать правила валидации и связи, что давало неплохой набор для бутстрапинга миграции. Сейчас связи отпадают…
Ну или еще применение, от которого я не готов отказаться, так что для части своих моделей я таки вернусь к старому синтаксису переопределив магию — хочу сделать в своем приложении генератор запросов по аналогии с 1с-построителем запросов, т.е. GUI-формочку в которой есть все уместные для этой задачи модельки, их свойства, связи, и тыкая мышкой можно настроить запрос с простейшими join, unit sum условиями и т.п.
От идеи смотреть на внешние ключи схемы базы отказался потому что кое-кто из упомянутых тут ребят очень долго распевал мне о том как удобно в юии2 работать со связыми между моделями из разных СУБД и всё такое… :)
Круто! Лично для меня самое ожидаемое из этих фич, это расширение asset-ов.
Так и не проникся asset'ами и ушёл на grunt.
Вот кто-то минуснул, а я же это не сам придумал: yii2-cookbook.readthedocs.org/structure-asset-processing-with-grunt
Sign up to leave a comment.
Yii 2.0.6