пасиба

нельзя полагаться на то что в $pages будет нулевой элемент

народ, вопрос немного архитектурный.

представим, есть некая сущность (заказ), у нее есть три поля - город, адрес, транспорт, а у заказа три статуса - новый, подтвержденный и в работе

1) Первый шаг за пользователем, он создает заказ (статус - новый**), заполняет **город обязательно, адрес по желанию

итак, есть заказ
например, такой

id: 1
city: Saratov
address: null
transport: null

2) Второй шаг за менеджером - он звонит юзеру, подтверждает заказ, если не заполнен адрес, уточняет по телефону и списывает его.

Нельзя перевести систему в статус подтвержденный без адреса

3) Ищется транспорт, как только нашли - переводим заказ в статус в работе

ВОПРОС

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

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

Или это неправильно?.. Как верней здесь делать?

Это просто для учебы. А какие есть варианты?

не полагаться

а ты харош

first()?

у тебя там массив

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

У тебя админ случайно тыркнет и проебёт данные пользователя

а вот это неплохой совет...

@web_username @mrTeo

Подскажите, пожалуйста. Если я в админке удаляю из БД город, то нужно метод удаления города: писать в CityController, в AdminController или создавать отдельный контроллер для админки, который с городами работает, типо AdminCityController?

ну по сути тебе же города не только в админке нужны

Метод это не контроллер

Я просто не совсем понимаю нужно ли разделять работу с городами в админке и работу с городами не в админке

Как бы модель одна и та же, но с контроллерами сомнения берут

можешь просто отделить код админки и фронта в под папках
типа
Controllers/Admin
Controllers/Client

соответственно, тогда префикс уже не нужен

А что по поводу разделения, я считаю что нужно разделять, но при этом один контроллер должен работать с одной сущностью, то есть как крад контроллер

в свою очередь, если код большой, то можно вынести в отдельный инвокейбл контроллер

Спасибо. Так и сделаю. Разделю по папкам