примерно так в апи

ты не понял, я про структуру стандартную. модуль должен состоять из тех же моделей контрлоллеров и видов а у тебя там вообще шурум бурум )))

https://github.com/yiisoft/yii2/issues/1467 только после этого issues а лучше сделать чтобы контроллеры, как и все остальные классы, могли быть размещены в произвольных местах и неймспейсах. Тогда можно забыть о всяких адвантедах

ты не понял, я про структуру стандартную. модуль должен состоять из тех же моделей контрлоллеров и видов а у тебя там вообще шурум бурум )))

странное понимание: виды не обязательны же а вдруг в контроллере генерится xml'ка? для неё тоже отдельный вид делать?

ты не понял, я про структуру стандартную. модуль должен состоять из тех же моделей контрлоллеров и видов а у тебя там вообще шурум бурум )))

нэпонятно мне)

а что? где папка с контроллерами моделями и видами?

Это называется разделение логики по доменам

http://joxi.ru/nAyQxvZS1qoaAZ я тут не вижу папку controllers в модуле api

я про это говорю а не про виды

там, скорее всего, в субдиректориях отдельно модули

не вижу там же папки models

кто мне мешает на модулях строить структуру? )

там только одна папка v1

типа роутинг /api/v1/category/<контроллер>

мешает инструкция что в yii принято делать эти папки в модулях ))

http://joxi.ru/zAN4YzNUDqjPm9

а их там нет у тебя и меня это озадачило)))

api как модуль, v1 как модуль, и внутри каждой директории ещё модуль а инструкции - это всего-лишь набор рекомендаций

http://joxi.ru/zAN4YzNUDqjPm9

я прям ванга)

я прям ванга)

сам небось балушься

давайте, раз нас здесь уже много, вы мне подскажите такую вещь: кто-то сталкивался с стилизацией recaptcha?

никто же не агитирует за использование того или инного шаблона, тех или инных подходов самый правильный подход (в рамках MVC фреймворка) - использование парадигмы MVC, а как она будет реализована - разными приложениями, или разными модулями - зависит только от разработчика также и с любым другим функционалом: не нравятся виджеты - не используйте виджеты, не нравятся миграции - не используйте миграции)

MVC правильный это потому что трудно уйти от нее в yii2 не нравятся миграции - не используйте миграции) главное что бы было это только в своих пет-проектах.

MVC правильный это потому что трудно уйти от нее в yii2 не нравятся миграции - не используйте миграции) главное что бы было это только в своих пет-проектах.

ахах) ну я ж не говорил, что нужно так делать) просто кому-то это ни разу не удобно, как, например, использование GridView или ListView

сам небось балушься

не знал что можно так модуль внутри модуля ? а модель внутри модели? или контроллер внутри контроллера? есть еще какие то такие штуки не по инструкции? ?

не знал что можно так модуль внутри модуля ? а модель внутри модели? или контроллер внутри контроллера? есть еще какие то такие штуки не по инструкции? ?

ну это ты уже загнул) модуль внутри модуля можно, и не обязательно что у модуля будут модели или виды модуль состоит из двух вещей: директории, и файлика Module.php, остальное - на твоё усмотрение

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

ну это ты уже загнул) модуль внутри модуля можно, и не обязательно что у модуля будут модели или виды модуль состоит из двух вещей: директории, и файлика Module.php, остальное - на твоё усмотрение

ок ) не знал сего

не знал что можно так модуль внутри модуля ? а модель внутри модели? или контроллер внутри контроллера? есть еще какие то такие штуки не по инструкции? ?

Это один из удачных приемов. Так многие делают, попробуй) И в проекте чисто и сухо)

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

ну я писал, основываясь на своём мнении, так как уже не один проект сделал на базе advanced'а, и для меня такое разделение было удобно но при этом, для некоторых проектов, использую также и basic - когда не нужно делать никакого разделения

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

"внедренную идею" даже если идея правильная =) ? Может нужно вводить "внедренную идею" в yii2 сообщество ? А то посмотришь на сторонние модули, и плакать хочется

Я выношу общие модели в корень именную их как ModelnameRecord если они от AR в модулях наследую и нагружаю логикой модуля. Так же в модулях сущностей создаю свои модели от baseModel и называю их как ModelnameModel они служат при необходимости слоем трансляций

Но если проект большой все равно в финале ад)

а нельзя модели выносить в components ?

общие

Я выношу общие модели в корень именную их как ModelnameRecord если они от AR в модулях наследую и нагружаю логикой модуля. Так же в модулях сущностей создаю свои модели от baseModel и называю их как ModelnameModel они служат при необходимости слоем трансляций

такой же подход используется и в advanced, только вместо ModulenameModel есть нэймспейсы

"внедренную идею" даже если идея правильная =) ? Может нужно вводить "внедренную идею" в yii2 сообщество ? А то посмотришь на сторонние модули, и плакать хочется

"Внедренную идею", нужно осознать, т.е. понимать. Недостаточно знать, нужно понимать. Пример : "Я зная много вещей, но я не понимаю смысл некоторых". Вот именно с таким я и сталкиваюсь в основном. Да знают паттерны, но что с ними делать ? По сути — нет. Тяжело видеть недостатки чего-либо если до этого не видел ничего кроме этого. Это синдром утенка.

такой же подход используется и в advanced, только вместо ModulenameModel есть нэймспейсы

не Modulname a modelname , надеюсь это опечатка)

не Modulname a modelname , надеюсь это опечатка)

не, не опечатка) я думал, у вас опечатка) я чёт не подумал, что модель подписывается как *Model, если она и так в нэймспейсе /models

ибо получается /app/modules/users/models/UserModel

не, не опечатка) я думал, у вас опечатка) я чёт не подумал, что модель подписывается как *Model, если она и так в нэймспейсе /models

для удобства. сразу видно AR или от базовой модели

Модель не обязательно должна быть связана с хранилещем данных

а, понятно) вот тут у каждого свой подход - я AR модели называю {ModelName}Record

а, понятно) вот тут у каждого свой подход - я AR модели называю {ModelName}Record

Я так же) А если модель от базовой то просто {ModelName}Model

нэйминги у каждого свои) просто модели я обычно обзываю тем, что там есть (User, Category, Post), формы - добавляю в конце Form, AR - Record для остального есть нэймспейсы

нэйминги у каждого свои) просто модели я обычно обзываю тем, что там есть (User, Category, Post), формы - добавляю в конце Form, AR - Record для остального есть нэймспейсы

гут. в целом кажется подход в какой-то книге описывался по yii про именование моделей

Ребят, вот все тут защищают шаблон advanced. Ок. хоть я и не разделяю такое мнение. Пример.Есть заказы, есть водители и клиенты. Модель Order в common. Её наследуют в модулях "клиент" и "водитель". В Order есть общая логика валидации. Например человеку, отвественному за модуль "клиента" вдумалось переписать валидацию для определенной ситуации, он добавил сценарий и переопределил метод rules, через parent:: получил правила. Но неожиданно запорол одно из общих правил валидации. Вот это хорошо ? А ведь по сути мы ожидаем что ОБЩАЯ ВАЛИДАЦИИ, должна работать НЕЗАВИСИМО от того сделали мы проверку или нет.

Ребят, вот все тут защищают шаблон advanced. Ок. хоть я и не разделяю такое мнение. Пример.Есть заказы, есть водители и клиенты. Модель Order в common. Её наследуют в модулях "клиент" и "водитель". В Order есть общая логика валидации. Например человеку, отвественному за модуль "клиента" вдумалось переписать валидацию для определенной ситуации, он добавил сценарий и переопределил метод rules, через parent:: получил правила. Но неожиданно запорол одно из общих правил валидации. Вот это хорошо ? А ведь по сути мы ожидаем что ОБЩАЯ ВАЛИДАЦИИ, должна работать НЕЗАВИСИМО от того сделали мы проверку или нет.

странный вопрос ожидаем такой же странный ответ) вопрос касательно ООП или yii ?

Что именно мне уточнить, чтобы стало понятно ?

странный вопрос ожидаем такой же странный ответ) вопрос касательно ООП или yii ?

Вопрос касательно шаблона advanced и того как его обычно используют.

Надо что-то переопределить для частного случая ? Переопределяй метод!

Вот такое говно.

Ребят, вот все тут защищают шаблон advanced. Ок. хоть я и не разделяю такое мнение. Пример.Есть заказы, есть водители и клиенты. Модель Order в common. Её наследуют в модулях "клиент" и "водитель". В Order есть общая логика валидации. Например человеку, отвественному за модуль "клиента" вдумалось переписать валидацию для определенной ситуации, он добавил сценарий и переопределил метод rules, через parent:: получил правила. Но неожиданно запорол одно из общих правил валидации. Вот это хорошо ? А ведь по сути мы ожидаем что ОБЩАЯ ВАЛИДАЦИИ, должна работать НЕЗАВИСИМО от того сделали мы проверку или нет.

Не переживай. я не защищаю =)

Вопрос касательно шаблона advanced и того как его обычно используют.

шаблон это просто структура папок. у тебя есть кстати сценарии еще в добавок, крути что душе угодно) главное потом разобраться во всем этом)

я думаю сравнительно малый % пишет строго в эдванс по рекомендации )

или только свой первый проект на yii

Надо сюда Макарова бы позвать

шаблон это просто структура папок. у тебя есть кстати сценарии еще в добавок, крути что душе угодно) главное потом разобраться во всем этом)

Если у тебя все через наследование то по сути ничего не разделяется. Хоть пусть overadvanced шаблон. Нужно писать интерфейсы для взаимодействия с твоим кодом (А этого никто не делает, потому что не хватает практики командной работы.) Так вот, я заявляют что 90 процентов кода который я видел в advanced - это просто наследование из common - всё.

Ребят, вот все тут защищают шаблон advanced. Ок. хоть я и не разделяю такое мнение. Пример.Есть заказы, есть водители и клиенты. Модель Order в common. Её наследуют в модулях "клиент" и "водитель". В Order есть общая логика валидации. Например человеку, отвественному за модуль "клиента" вдумалось переписать валидацию для определенной ситуации, он добавил сценарий и переопределил метод rules, через parent:: получил правила. Но неожиданно запорол одно из общих правил валидации. Вот это хорошо ? А ведь по сути мы ожидаем что ОБЩАЯ ВАЛИДАЦИИ, должна работать НЕЗАВИСИМО от того сделали мы проверку или нет.

Не совсем понятна задача и реализация Если в order уже есть валидация, и нужно добавить еще одно правило, специфичное для модуля, то в rules модели модуля нужно сделать своё правило, добавив его ко всем остальным через array_merge (или ArrayHelper) с parent::rules() Типа array_merge(parent::rules, [custom rule]

Не совсем понятна задача и реализация Если в order уже есть валидация, и нужно добавить еще одно правило, специфичное для модуля, то в rules модели модуля нужно сделать своё правило, добавив его ко всем остальным через array_merge (или ArrayHelper) с parent::rules() Типа array_merge(parent::rules, [custom rule]

И вот тут-то можно все запороть.

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

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

То есть, в данном кейсе у меня бы была OrderForm со своими правилами, в методе save которой была бы логика сохранения в AR

а что вам мешает использовать сценарии?

для каждого случая

тем самым не создавая формы если те не являются составными

да блин чё вы придумываете, я не понимаю. Могу я в отнаследованной модели игнорировать правила родительской ? Да. Остальное — мимо.

ERROR: S client not available

а что вам мешает использовать сценарии?

Лично я не сильно еще гуру в yii, и сценариями пользоваться не совсем научен, но в формах можно реализовать много лишней логики, применимой к конкретной форме Например, загрузка фоток

Много людей Advanced шаблон используют ?

Для меня легче advanced, нежели basic

Лично я не сильно еще гуру в yii, и сценариями пользоваться не совсем научен, но в формах можно реализовать много лишней логики, применимой к конкретной форме Например, загрузка фоток

тут идет речь о компонентном подходе

В общем, ладно. Может это у меня только такие проблемы. Из-за наследования из common, многое ломается не там где должно. Пример: Есть Модель, которая заполняется данными из API, я написал гидратор для модели, и кинул модель в common. Теперь новый человек, отвечающий за часть другого апи, отнаследовал модель и затер какие-то данные, теперь API его не впускает, когда собирается запрос и отправляется. А в коде мы это не увидем. ТОлько в рантайме. Тесты конечно тоже надо писать. Но не всегда получается вс1 покрыть тестами.

Я бы бил за наследования из common

когда же будут в пхп финал классы

когда же будут в пхп финал классы

да хоть final методы бы использовали. Даже этого не делают многие.

когда же будут в пхп финал классы

final class Classname {}

Я бы бил за наследования из common

и за ооп тоже бить надо )

а мы извращенцы тут множественное наследование хотим)

и за ооп тоже бить надо )

Правильно давайте писать процедурщину.

Нужно бить просто так)) Не нужно причин. )))

Нужно бить просто так)) Не нужно причин. )))

Вам в другую группу)

final class Classname {}

Они не совсем так как в джаве работают.

а мы извращенцы тут множественное наследование хотим)

И отстрелись тебе ногу ?

Они не совсем так как в джаве работают.

главное запрещают наследоваться или нужен другой эффект)

Нужно вообще в коллективе иметь сумешедшего кодера-убийцу, который бы бегал с ножом за ошибки)) P.S. который сам будет писать неплохой код.

Нужно вообще в коллективе иметь сумешедшего кодера-убийцу, который бы бегал с ножом за ошибки)) P.S. который сам будет писать неплохой код.

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

Коллеги, добрый вечер! Подскажите. Загружаю файл, всё хорошо. Но если сделать у него свойство обязательной загрузки ('skipOnEmpty' => false, либо добавить в required), то ломается - модель из вью приходит с пустым файлом. То есть валидация не проходит, даже если файл кладешь. А если без этого флага, то загружается файл. https://gist.github.com/anonymous/f1dcfef7a582b0cb0c123f9f87bb4e43

Мне кажется, upload нужно делать перед валидацией

Мне кажется, upload нужно делать перед валидацией

Имеешь в виду $model->image->saveAs()? Ну это слегка нелогично и мануалы подсказывают наоборот,

Мне кажется, upload нужно делать перед валидацией

Не, так нельзя. зачем лишняя кака на сервере

Имеешь в виду $model->image->saveAs()? Ну это слегка нелогично и мануалы подсказывают наоборот,

Решил! Нужно получать $model->image = UploadedFile::getInstance($model, 'image'); до validate()

Всем привет! Есть экшн: function actionXyu($param) { ..... } как мне в urlManager'е прописать параметр $param? например 'GET url/to/xyu' => 'path/to/url/xyu?param=pizda'

Нахуй отошли запрос)

?

Всем привет! Есть экшн: function actionXyu($param) { ..... } как мне в urlManager'е прописать параметр $param? например 'GET url/to/xyu' => 'path/to/url/xyu?param=pizda'

Читайте доки там это есть. Это же классический случай.

Зачем, если у него порно намечается)

весна видимо

гармоны

гармоны

Удалите плиз это.

Зачем, если у него порно намечается)

))