Я не за производительность, а за саму проверку типов больше

цитатка Марко с externals: > Still, the fact that references are properly typed mitigates the issue for my shady use-cases (I've got a reputation there), самоирония это всегда хорошо :D

вот не уверен в профите типизированных свойств...

в целом в большинстве случаев там типы выводятся

в целом в большинстве случаев там типы выводятся

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

Как раз теми, что в большинстве случаев закрывается тем же псалмом

Как раз теми, что в большинстве случаев закрывается тем же псалмом

зато псалм юзать не придется

зато псалм юзать не придется

да придётся всё равно

у меня на проекте вывод типов чуть более 98% псалм рисует. но помимо типов он ещё всякое проверяет

как сделать тонкий єкшен в контролере есле нужно срендерить вюху с большим количеством параметров: $isMobile = $this->container->get('mobile_detect')->isMobile(); $providers = $this->getDoctrine()->.... .... $data = [ 'providers' => $providers, 'isMobile' => $isMobile, .... ]; return $this->render('index.html.twig', $data);В результате каждая переменная для вюхи достается 1-2 строчками, а в суме получается толстой екшен. Думал в командбас засунуть и дернуть команду в контролере, но тогда не совсем понятко как отдать респонс с басхендлера и сам рендер вызвать.

тонкий контроллер - эт не про кол-во символов

команда - это не про получение данных

если так хочешь - сделай какой-нибудь DataProvider, но смысла в этом не вижу

команда - это не про получение данных

понимаю, поетому и не хочу юзать ее в таком контексте

более того - дергать контейнер зло дергать getDoctrine тоже зло - репозитории есть

тонкий контроллер - эт не про кол-во символов

ну если с такой стороны посмотреть то да) но всеже хотелося сделать и строчек менше

ну если с такой стороны посмотреть то да) но всеже хотелося сделать и строчек менше

с любой

более того - дергать контейнер зло дергать getDoctrine тоже зло - репозитории есть

а как без $this->get() тогда

а как без $this->get() тогда

автовайринг для кого придумали?

пока не дошол к нему

дойди

все просто

инжекти сервисы в экшн и используй их про доктрину я тоже сказал - репозиторий используй

ето большая перемена для мого проекта) не все так просто

мб стоит всё же сесть, почитать, подумать, а потом уже спрашивать? вот серьёзно

а то кажется мне, что ты qb там прям в контроллере дергаешь

ето большая перемена для мого проекта) не все так просто

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

ничего не изменится кроме того, что ты сможешь инжектить сервисы в экшн

инжекти сервисы в экшн и используй их про доктрину я тоже сказал - репозиторий используй

$this->getDoctrine()->getRepository() - так я и использую

$this->getDoctrine()->getRepository() - так я и использую

репозитории как сервисы

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

попробую

репозитории как сервисы

а в таком плане

окей спасибо

Есть правило: "никнейм должен быть уникальным". Тогда, насколько я понимаю, нужно его: 1. Проверить в валидации перед созданием сущности с никнеймом. 2. Соблюдать во время выполнения каких-то действий. Каким образом соблюдать это правило на уровне домена? Ведь нельзя вытащить из БД все записи =\ (вытаскивать только никнеймы? о_О) Есть ещё ограничение через уникальный индекс в БД, но это уже проверка на уровне хранилища. Стоит вообще этим заниматься или положиться на хранилище?

повесить юник констреинт и не париться

Есть правило: "никнейм должен быть уникальным". Тогда, насколько я понимаю, нужно его: 1. Проверить в валидации перед созданием сущности с никнеймом. 2. Соблюдать во время выполнения каких-то действий. Каким образом соблюдать это правило на уровне домена? Ведь нельзя вытащить из БД все записи =\ (вытаскивать только никнеймы? о_О) Есть ещё ограничение через уникальный индекс в БД, но это уже проверка на уровне хранилища. Стоит вообще этим заниматься или положиться на хранилище?

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

репозитории как сервисы

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

повесить юник констреинт и не париться

Тогда в валидации тупо проверять через метод репозитория, есть ли уже такой никнейм? Или ловить эксепшен от БД?

Тогда в валидации тупо проверять через метод репозитория, есть ли уже такой никнейм? Или ловить эксепшен от БД?

эксепшен

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

it depends, как обычно

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

А вообще можно юзать paramConverter и в контроллере получать не репозиторий а сразу его результат

А вообще можно юзать paramConverter и в контроллере получать не репозиторий а сразу его результат

сегодня это называется argument value resolver

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

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

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

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

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

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

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

транзакции?

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

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

транзакции?

а как они помогут?)

главное слово знакомое вспомнить

а там пойдет дело

главное слово знакомое вспомнить

ещё можно про лок вспомнить)

а как они помогут?)

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

ещё можно про лок вспомнить)

да) тогда и транзакции будут в тему почти)

транзакции?

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

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

оно отдает название индекса который не дал

этого достаточно

а вообще - нахера тебе уникальный И email И nickname?

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

это как "confirm password" - увидели где-то лет 10 назад и все еще лепят

культ карго

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

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

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

не обязательно уникальным

это было бы глупо

это как "confirm password" - увидели где-то лет 10 назад и все еще лепят

это очень полезная вещь на самом деле ;)

это очень полезная вещь на самом деле ;)

я о том и говорю

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

а еще есть веселье - возможность "сменить" юзернейм)

спасибо, что подсказали! Надеюсь мои вопросы не слишком глупые

ERROR: S client not available

не обязательно уникальным

Обязательно если делаешь авторизацию через email OR username и ты уверен что найдёшь только одного юзера что бы там не ввели

Обязательно если делаешь авторизацию через email OR username и ты уверен что найдёшь только одного юзера что бы там не ввели

ну и нахер тебе такая авторизация?

чем только email не угодил?

Удобство пользователя

в чем удобство?)

пользователь будет полагаться больше на менеджер паролей своего браузера

Никнейм короче

автозаполнение браузера

ты не те вещи оптимизируешь

если уж заботишься об удобстве - сделай возможность зайти через фэйсбук какой

помимо email + password

пользователь будет полагаться больше на менеджер паролей своего браузера

С такой логикой заставляй юзеров генерировать пароли, всё равно автозаполнение ведь

А безопасность прибавится

С такой логикой заставляй юзеров генерировать пароли, всё равно автозаполнение ведь

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

прям на клиенте предложу

ну и по поводу заставлять - просто проверка на top1000 популярных паролей

или опять же авторизация через фэйсбук - тогда пароль не наша забота

максимально удобный вариант

для всех

Ну короче хз, но я уже несколько лет на своих проектах делаю вход через username or email + иногда соц сети и никто не жаловался, а ещё люблю минимальный пароль делать 4 символы, потому что юзер сам должен отвечать за свою безопасность, а я ему только удобство предоставляю

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

Ну короче хз, но я уже несколько лет на своих проектах делаю вход через username or email + иногда соц сети и никто не жаловался, а ещё люблю минимальный пароль делать 4 символы, потому что юзер сам должен отвечать за свою безопасность, а я ему только удобство предоставляю

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

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

мне кажется имя фамилия - это какая-то подстава, если они будут в паблике светиться

я просто сужу по себе - если мне нужен какой-то сервис и там нет входа через соц сети и возможности за 2 минуты что-то потыкать - я ухожу. Возвращаюсь если реально ничего не нашел и все еще надо.

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

Ну опросы не проводил, но контактные данные есть в футере, если что то конкретно не нравится - думаю написали бы

Ну опросы не проводил, но контактные данные есть в футере, если что то конкретно не нравится - думаю написали бы

наивный

люди просто уходят

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

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

смотря что это за сервис

просто лень запоминать 100500-ый пароль к 100500 сервису куда зашел только посмотреть что это вообще такое

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

и приложение им очень нужно должно быть