для изоляции backend, frontend приложения и связующий common

Не нужно так делать. Эти common это как Коребандлы в симфони. не понятно зачем

Я использовал, так как старший сказал Сейчас я понимаю, что он усложняет все

Я использовал, так как старший сказал Сейчас я понимаю, что он усложняет все

Возьми лучше @nurik6 в старшие

Старшего давно нет

Я не против поучиться)

так вот вчера в advonced я писал одну проблему с identityClass который проставляет common/models/User хотя в конфиге другое прописываю

где он его перезатирает непонятно

Вот пример, почему плох Advanced. У меня есть юзеры. Я создал модель в common. И тут все отлично. Потом в Backend какой-то чувак создаёт модель и наследует эту модель из common от юзеров (Спец клиенты) и часть данных забирает из API т.е. модель заполняется из нескольких мест. Теперь я беру и меняю что-то в common и пиздец.

Дим, я тебя не узнал

=)

Вот пример, почему плох Advanced. У меня есть юзеры. Я создал модель в common. И тут все отлично. Потом в Backend какой-то чувак создаёт модель и наследует эту модель из common от юзеров (Спец клиенты) и часть данных забирает из API т.е. модель заполняется из нескольких мест. Теперь я беру и меняю что-то в common и пиздец.

тут какое то больше не понимание в команде) мне так кажется)

Мне кажется тут ошибка в том что модель наследуется Получается где то что то новое А где то все по старому

Гит же склеивает код зачем модель размножать

Мне кажется тут ошибка в том что модель наследуется Получается где то что то новое А где то все по старому

Да вот проблема в том, что мало того, что непонятно для чего этот шаблон. Так еще это даёт простор чтобы адски косячить.

у меня есть common модели то есть common/AR от него наследуется Object и там вся логика

у меня есть common модели то есть common/AR от него наследуется Object и там вся логика

Плохо.

Чем?

Чем?

Я об этом написал выше. Я отдал Backend одному чуваку и сказал пили админку. Он начал пилить и чтобы меньше работать, он начал наследовать мои модели из common. Всё.

Я поменял что-то в моделях и здравствуй гидракод.

Ну так это твой работник А для меня удобно тем что я допустим добавил поля, связи перегенерил модель через gii и добавил логигу в унаследованный от этой модели

Я бы тебя тоже убил за это

Что в этом плохого? Дим, твой аргумент какой

зачем наследовать ? и зачем там логика ?

Я выше написал Дим

Что перегенерил быстро структуру, что то удалил, что то добавил в наследнике

меньше телодвижений

Ну так это твой работник А для меня удобно тем что я допустим добавил поля, связи перегенерил модель через gii и добавил логигу в унаследованный от этой модели

Я новый работник мне дали твой проект. Я открываю код и вижу так вот у него модели. Так логика там же. Ок. Теперь я начинаю писать код. Я предполагаю что мы с тобой договоримся что ты предоставляешь мне готовые модули с которыми я могу работать. Но ты мне даешь common как core. Есть общая логика, которую нужно переписать для частного случая. Я лезу в твой common и все. Теперь ничего не работает. Я просто встаю и больше не возвращаюсь сюда.

меньше телодвижений

а потом новый работник будет искать. "а что это все поломалось"

а кто, или что тебе мешает документацию сделать?

Нельзя доверять человеку. Нужно создавать интерфейсы на уровне кода. Даже себе не надо доверять. Модульный подход лечит от ошибок лени.

Нурик, дай почитать по этот подход

солид же , там всякие сервисные слои, di и т.д

Developer.uz

Тут хорошо пишет

в блоге у нее

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

http://shot.hsdn.org/HVFH6hXS

как то так

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

Давайте разберемся )

Advanced и Basic это всего лишь точки входа выглядящие слегка по разному.

в адвенсед миграции встроены уже, инициализация какая то, файлы по другому называются, и в ообще мне кажется грамоздким ) хотя в инете в каждый пример пичкают этот адвенсед ?

хеллоу гайс!

http://shot.hsdn.org/HVFH6hXS

плюсую!

я могу Serializer изменить свойство из акшина?

это не позорно? )

жизнь коротка чтобы думать о позорах ))

второй шанс все равно не дают ?

может подскажите как получить доступ к этому поведению

ой все готово

не нужно)

$this->controller и все дела

ой всё

привет всем! вложу немного своего в холивар advanced против basic правильно @sizepermru написал, что они отличаются только точками входа advanced это как несколько basic (те, frontend и backend, по сути, те же basic), просто иногда нужно разделять админский функционал, и пользовательский например, в одном моём проекте (интернет-магазин) на backend'е была вся админка (и модулем получилось-бы не айс, ибо под каждый определённый функционал (менеджмент категорий, товаров, заказов, пользователей) был свой модуль - так проще)), а на frontend'е - весь интерфейс магазина (то есть, пользовательская часть) в common/models были общие модели (в моём случае - все AR), в каждом приложении (backend/frontend) были свои модели, иногда (а точнее, почти всегда) унаследованые от common моделей если у вас в команде нет общего понимания, зачем нужно использовать разделение - тогда и возникает вопрос "а зачем вообще advanced"

в общем, суть advanced в том, чтобы не создавать кучу модулей в basic, а разделять это на разные зоны - frontend и backend, как в базовом advanced'е

потом в этом проекте добавилась касса - отдельный cashbox app (как frontend или backend), со своими модулями, своими моделями

потом нужно было добавить api - добавился по аналогии с cashbox'ом api

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

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

Ну начнем холивар

да ну

насчёт документации: да, согласен - код должен быть таким, чтобы и без документации не возникало вопросов как его использовать. Но документация - это способ описать для "будущих поколений" что делает ваш метод, а не область его применения область применения - это уже местоположение той или инной модели в backend или frontend app (в advanced шаблоне), и если я вижу в backend/models какую-либо модель, я понимаю, что эта модель заточена конкретно для использования в backend app, пусть она и наследуется от common при этом, никто же не мешает в advanced app использовать common модели в чистом виде

не нравится шаблон сделай себе как удобно )

не нравится шаблон сделай себе как удобно )

плюсую, при этом на просторах github'а этих шаблонов как го*на

лучше подскажите либу для crop и resize , не виджен я просто сахар для работы с имаджем

Ну начнем холивар

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

привет всем! вложу немного своего в холивар advanced против basic правильно @sizepermru написал, что они отличаются только точками входа advanced это как несколько basic (те, frontend и backend, по сути, те же basic), просто иногда нужно разделять админский функционал, и пользовательский например, в одном моём проекте (интернет-магазин) на backend'е была вся админка (и модулем получилось-бы не айс, ибо под каждый определённый функционал (менеджмент категорий, товаров, заказов, пользователей) был свой модуль - так проще)), а на frontend'е - весь интерфейс магазина (то есть, пользовательская часть) в common/models были общие модели (в моём случае - все AR), в каждом приложении (backend/frontend) были свои модели, иногда (а точнее, почти всегда) унаследованые от common моделей если у вас в команде нет общего понимания, зачем нужно использовать разделение - тогда и возникает вопрос "а зачем вообще advanced"

Люди используют модули не как нужно. Они должны быть самодостаточны и не зависеть не от чего. с админкой так не получится. Ибо вы все равно зависите от внешних факторах . И зачем разделять на комон и дальше... если есть нейспейсы. Вполне не плохо весь мир разделяет функционал на домены(не веб домены) Просто в иий так сложно сделать из-за ограничений фреймворка вот и придумали костыли типо адвантед

ERROR: S client not available

лучше взять бейс и клепать самому в модулях. модуль api/control/console и так далее

http://joxi.ru/nAyQxvZS1qoaAZ

как-то так делаю всегда

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

и так ник-то не исключает криворукости разработчиков. Вон выше люди наследуют комон модели. Я уже не говорю что наследование это рак

насчёт модулей: никто не говорит, что модули совсем не самодостаточны они самодостаточны в рамках app'а возможно, понятие модуля в yii от понятия "модуль" в принципе у меня кардинально отличаются, так как я вижу модуль как возможность отделить какой-то большой функционал от общего так, чтобы его работа не сказалась на работе остального приложения, ну и при этом упорядочить файлы так, чтобы новичку было понятно что к чему

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

если в конце проекта не хочется себя убить, то ты хорошо поработал

как мне показывает практика, модули в разных фреймворках это совсем разные понятия в zend'е у нас модуль - это отдельное приложение, и чтобы сделать возможность использования для нескольких модулей общих моделей мне понадобилось много времени в yii тот же функционал реализован в рамках разных app'ов - frontend'а и backend'а кейс: приложение для перевода денег от одного человека другому необходимые "модули" или "приложения" - кабинет, в котором пользователь регистрируется, и добавляет кошельки\карточки, а также способы, по которым ему можно перевести деньги, и премерчант, на который попадает человек (всё равно какой - пользователь нашей системы или нет), и переводит деньги пользователю в yii я-бы сделал это при помощи advanced шаблона: в backend'е был-бы функционал пользователя, в frontend'е - премерчант; на zend'е это разные модули - cabinet и premerchant соответственно при этом, логически, получается та же херня, только в профиль - то же разделение на поддомены, только точка входа получается одна, и нужно было больше городить костылей чтобы заставить это работать

насчёт модулей: никто не говорит, что модули совсем не самодостаточны они самодостаточны в рамках app'а возможно, понятие модуля в yii от понятия "модуль" в принципе у меня кардинально отличаются, так как я вижу модуль как возможность отделить какой-то большой функционал от общего так, чтобы его работа не сказалась на работе остального приложения, ну и при этом упорядочить файлы так, чтобы новичку было понятно что к чему

а должны быть. Иначе теряется их смысл. Вот примерное требование к модулям: Возможность свободно включать и выключать любые модули. Приложение должно корректно работать с любым набором модулей. Но так же модули должны иметь возможность взаимодействовать друг с другом: обмениваться данными и командами. Каждый модуль может иметь несколько версий, которые тоже должны безболезненно заменяться. Это позволяет добиться большой гибкости. Мы просто разрабатываем две версии модуля и подключаем ту, которая нужна текущему пользователю. Модули должны быть самодостаточными. Это следствие первых двух требований. Если модуль может быть в любой момент добавлен/удален, он должен содержать в себе все, что необходимо для его работы, и абсолютно не зависеть от других модулей. ну и при этом упорядочить файлы так, Есть нейспейсы. создаем папку и все. Ну да с котроллерами мы так сделать не сможем из-за ограничения фрейма.

`в yii тот же функционал реализован в рамках разных app'ов - frontend'а и backend'`` это все костыли из-за ограничения фрейма

nuff said каждый видит в чём-то костыли, а в чём-то хорошие решения) где-то кто-то выше писал, что yii уже лет на 6 этак отстал от современной веб-разработки, но почему-то он всё ещё востребован)

Из-за Макарова

Если бы не Макаров, он бы у вас (СНГ) не был бы популярен

тот же zend, я считаю, уже лет этак на 10 отстал от веб-разработки, так как большинство решений в нём - грубые костыли (чего стоит только подтягивание вьюшек по названию action'а), но он опять-же востребован)

Если бы не Макаров, он бы у вас (СНГ) не был бы популярен

недавно предлагали работу в ОАЭ, на новом проекте, который собирались разрабатывать на yii2

хотел-бы я, чтобы ОАЭ было СНГ)

В других странах фреймом пользуется 2.5 человека.

Ну это уже вне темы

опять же, выше кто-то писал, давно-давно, что для разного уровня проектов лучше выбирать своё кому-то нужно что-то быстро и "дёшево" сделать - yii что-то среднее - лара что-то посложнее - симфа

nuff said каждый видит в чём-то костыли, а в чём-то хорошие решения) где-то кто-то выше писал, что yii уже лет на 6 этак отстал от современной веб-разработки, но почему-то он всё ещё востребован)

Естественно это зависит от разработчика. Кто-то не видит проблем и не видел других решений и будет считать так, а кто-то по другому

в общем, мы начали холивар на тему "basic vs advanced" а сейчас вы доказываете что yii говно)

немного не туда повернул наш диалог)

advanced нужен, когда не нужны модули

я просто пытаюсь объяснить рациональность использования advanced шаблона в тех случаях, когда basic будет строиться на одних модулях

Единственный плюс адвантеда это он помогает решить "проблемы" фрейма

http://joxi.ru/nAyQxvZS1qoaAZ

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

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

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

в апи?

да

виды в апи? )

Единственный плюс адвантеда это он помогает решить "проблемы" фрейма

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