Кто нибуд пробовал на sulu.io в form-bundle отправлят attachment на почту ? У мне null вернет. не разобрался

если в доктрине использовать single table inheritance - мне обязательно нужны отдельные репозитории типа AdminRepository, ManagerRepository, или можно обойтись одной репой?

Можно обойтись одной, но лучше разделить) общее пихать в UserRepository

так, а если например я имею на руках user id, как будет выглядеть "найти такой то тип юзера" если я заранее не знаю к какому типу он относится?

блин кажется это просто гемор какой та (

Нет

так, а если например я имею на руках user id, как будет выглядеть "найти такой то тип юзера" если я заранее не знаю к какому типу он относится?

ищи общий и проверяй через instanceof

так, а если например я имею на руках user id, как будет выглядеть "найти такой то тип юзера" если я заранее не знаю к какому типу он относится?

Get type

Юзер у тебя абстрактный

Get type

ну или разделяй сущности)

ну да

разделяй и властвуй

ну или разделяй сущности)

А бля, это клас тейб наследование

Я тупанул

Сорян

если в доктрине использовать single table inheritance - мне обязательно нужны отдельные репозитории типа AdminRepository, ManagerRepository, или можно обойтись одной репой?

Для каждой сущности нуже свой репозиторий, типы сами проаеряются

а в какой репозиторий тогда обращаться чтобы получить сущность если я не знаю тип заранее?

а в какой репозиторий тогда обращаться чтобы получить сущность если я не знаю тип заранее?

В репозиторий который определенн для сущности с которой начинается сингл тейбл

нда, точно так

В чем разница между Sensio\FrameworkExtraBundle\Route и Symfony\FrameworkBundle\Route?

неймспейсы сокращены

Первый - в аннотациях позволяет роуты прописывать

Второй - собственно класс роута

Каждый роут при прогреве кеша превращается в класс Symfony\FrameworkBundle\Route и потом компилируется в пхп в кеш

Из офф доки. Первый вообще не используется, хотя аннотация Route есть

Хм

Значит они вкрутили аннотацтт в сам компонент

Раньше для этого нужен был FrameworkExtraBundle

Вот и я удивился, зачем тогда от Сенсио)

подскажите, пожалуйста, как лучше всего реализовать задуманное: надо чтобы в dev-окружении эндпоинты с апи были доступны по адресу localhost:8000/api/v1/, а в продакшене по адресу `api.example.com/v1/`. был вариант в .env создать переменные API_PREFIX и API_HOST и использовать их в routes.yaml, но так нельзя: вываливается с ошибкой "Using "%env(API_PREFIX)%" is not allowed in routing configuration." (симфони 4, бандлов для реализации реста нет)

Привет народ. Мне нужен ваш совет. Есть задача - удостовериться, что у пользователя в системе актуальная информацию в профиле - номер телефона и email. Первая мысль, это при успешной авторизации и время последней авторизации дольше определенного периода (к примеру 180 дней) на главной странице отобразить модальное окно с формой подтверждения своих данных. Но проблема в том, что после авторизации fos user автоматически меняет поле last_logined. Тем самым в контроллере у $this->getUser()->getLastLogin() стоит текущая дата

Привет народ. Мне нужен ваш совет. Есть задача - удостовериться, что у пользователя в системе актуальная информацию в профиле - номер телефона и email. Первая мысль, это при успешной авторизации и время последней авторизации дольше определенного периода (к примеру 180 дней) на главной странице отобразить модальное окно с формой подтверждения своих данных. Но проблема в том, что после авторизации fos user автоматически меняет поле last_logined. Тем самым в контроллере у $this->getUser()->getLastLogin() стоит текущая дата

Я думаю, что нужно добавить некий обработчик AbsentForLongTimeHandler, который пишет в сессию некую переменную - oldUser (bool) и в контроллере работать с этой переменной из сессии. Но не усложняю ли я?

Усложняешь) почему просто дату регистрации не сохранить а отдельное поле?

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

Зачем это поле вообще пользователю показывать?

подскажите, пожалуйста, как лучше всего реализовать задуманное: надо чтобы в dev-окружении эндпоинты с апи были доступны по адресу localhost:8000/api/v1/, а в продакшене по адресу `api.example.com/v1/`. был вариант в .env создать переменные API_PREFIX и API_HOST и использовать их в routes.yaml, но так нельзя: вываливается с ошибкой "Using "%env(API_PREFIX)%" is not allowed in routing configuration." (симфони 4, бандлов для реализации реста нет)

все, разобрался. стоило добавить parameters: api_prefix: '%env(API_PREFIX)%' api_host: '%env(API_HOST)%' в services.yaml и в настройках роутинга доставать параметры вместо переменных окружения

Зачем это поле вообще пользователю показывать?

Ну вот создал ты аккаунт на моем сайте два года назад с номером телефона, которым ты уже давно не пользуешься. И хочешь восстановить пароль. Что тогда?

Восстанавливаю его

Дату регистрации зачем обнулять?

Тебе надо показывать некоторое время спустя заполнения этих данных?

Восстанавливаю его

Если у тебя не актуальная информация на сайте, то не сможешь восстановить. Поэтому и нужно держать у себя в базе актуальную информацию о пользователях. Гугл кстати делает то же самое

То есть после смены номера тоже показывать?

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

То есть после смены номера тоже показывать?

В том то и дело, что если опираться на дату регистрации, то пользователю каждый раз при авторизации будет показываться это поле. А это неправильно. Либо придется добавлять дополнительное поле в таблицу

В том то и дело, что если опираться на дату регистрации, то пользователю каждый раз при авторизации будет показываться это поле. А это неправильно. Либо придется добавлять дополнительное поле в таблицу

"при" - это до или после?

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

Ааа, все допер. Нужно в любом случае добавлять дополнительное поле в таблицу (lastPhoneConfirmed - datetime). И если разница этой даты от текущей больше определенного периода, то показывать форму.

То есть тебе надо раз в некоторое время заново подтверждать номер телефона?

Спасибо, за правильные вопросы, которые вдохновили на решение)

То есть тебе надо раз в некоторое время заново подтверждать номер телефона?

Да

Не храни это в табличке с пользователями

В отдельную вынеси

Не храни это в табличке с пользователями

Почему?

В user оно не нужно

Это часть твоей бизнес-логики, а не одно из свойств пользователя

1. где хранишь бизнес логику (уточню - ложишь ли логику в сущности) 2. где делаешь flush

150+150 ^_^

забей, это туалетный юмор ))

- "в моделях" это где? я уточнил там вопрос. - ты загрузил сущность для изменения. Где и для чего ты будешь вызывать persist? других сущностей в работе не фигурирует.

что делает persist и почему его НЕ надо вызывать при изменении сущности)

)))

сколько лет ты там с доктриной работаешь?

А без persist где он хранится?)

Стейт этот

я не тролю, просто проверка людей которые будут помогать другим

ну просто из того что ты описываешь вырисовывается непонимание работы Unit of work

не поняли

"при каждой" что?

доктрина не очень эффективно это делает)