вообще для начинающих мб даж хорошая преза

ща досмотрю всю)

но вообще с сеттерами не ок

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

видео https://www.youtube.com/watch?v=rjtbCyacJas&t=160s

спс

спс

чет я загнался...

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

что бы на каждый query можно было сгенерить оптимальный гидратор

с инлайнингом всяких мелких функций

типа вместо $identity = $this->identityHash($row, $alias) делать $identity = "{$row['id_3']} {$row['type_4']}";

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

А напомните пожалуйста, какая там проблема с сонатой и симфони 3?

А напомните пожалуйста, какая там проблема с сонатой и симфони 3?

да вроде никакой, там проблема с сонатой + fos user на 3 ветки

а что за проблема с сонатой и фосюзером?

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

кажется sonata-user использует fos версии 1.* и поэтому на версию 3 не поставится. Но обещали как только fos 2 выйдет стабильный, это поправят. Не знаю поправили ли

А если не использую Фос Юзер бандл, то соната норм будет пахать на тройке?

Небольшой опрос есть. Для констант или свойств классов, где значение - FQCN что используете? 1. SomeClass::class 2. '\Vendor\Namespace\SomeClass'

кажется sonata-user использует fos версии 1.* и поэтому на версию 3 не поставится. Но обещали как только fos 2 выйдет стабильный, это поправят. Не знаю поправили ли

FosUser 2 вышел, но соната всё ещё от 1.3 зависит. Я буду FosUser выпиливать, видимо.

Небольшой опрос есть. Для констант или свойств классов, где значение - FQCN что используете? 1. SomeClass::class 2. '\Vendor\Namespace\SomeClass'

1

Просто забавный момент в том, что, если мне память не изменяет, в первом варианте автолоад срабатывает даже если больше нигде обращений к классу не будет. В Symfony, кстати, много где используются именно строки с именем. Хотя мне кажется, что это не ради избегания автолоада, а ради обратной совместимости с PHP старым.

Ну наверно да :) Я не интересовался. По логике наверно да. Он же должен его неймспейс достать.

Ну вот мне интересно, что будет в Symfony 4. Я не уверен, что они оставят строки, т.к. оверхед не особый должен быть. Да и в продакшене оно всё равно скомпилено будет.

Да, sonata-admin — (хорошо?) работает на 3.

Соната сама по себе да.

В смысле, SonataAdmin.

Ок. Спасибо :)

Какие у вас, кстати вообще впечатления на данный момент о 4 симфони?

Хочу пощупать на выходных, если время будет.

По словам Фабьена - круто. Но надо потрогать.

Теперь все будет по бест практис? :)

Один бандл и в нем домены.

да?

я больше 3.3 жду, ништяков с контейнером

По ссылке что ты прислал - вторая часть того, что ты хочешь сделать - аутентификация (а не авторизация, кстати). До этого тебе ещё надо клиенту токен выдать.

О, только проверил - вторая часть отлично работает Да, сейчас нужно сделать чтобы выдавался токен

Токен, соответственно, надо выдавать там, где не требуется аутентификация :)

я больше 3.3 жду, ништяков с контейнером

composer require symfony/dependency-injection:~3.3.*@dev

а нету случайно способа, чтобы посылал запрос на /login_check с логином и паролем, а в ответ выдавался токен?

а что до "стабильности" - они умудрились стабильную 3.2.7 сломать

composer require symfony/dependency-injection:~3.3.*@dev

до релиза осталось всего 3 недели) дождусь

а нету случайно способа, чтобы посылал запрос на /login_check с логином и паролем, а в ответ выдавался токен?

Это можно сделать, но ты же хочешь для API токены выдавать. Так что лучше это на отдельном ресурсе.

по коду уже именую сервисы по FQCN

Может добавить листенер на onAuthenticationSuccess типа такого, и возвращать там респонс

А что тебе мешает сделать обычный экшен в пределах своего API, который отдаст токен? Без листенеров?

абсолютно ничего))) но хотелось бы сделать максимально «правильно»

сейчас попробую по http://symfony.com/doc/current/security/guard_authentication.html - скорее всего получится, спасибо)

Будет ли корректно, если я репозиторий сделаю в виде сервиса (реализует UserProviderInterface) api.user.repository: class: AppBundle\Repository\UserRepository factory: ['@doctrine', getRepository] arguments: ['AppBundle\Entity\User'] и в security.yml добавлю провайдер по id'шнику? providers: api_user_provider: id: api.user.repository

Ну не то чтобы шибко хорошо, конечно. Всё же UserProvider по-хорошему ничего, кроме своей узкой задачи уметь не должен.

Да вот и думаю: по умолчанию репозиторий для User реализует UserLoaderInterface, а провайдер должен реализовать UserProviderInterface Чтобы не дублировать код, можно репозиторий реализовать с интерфейсом UserProviderInterface и далее его юзать Но то, что провайдер имеет доктриновский слой - не очень хорошо в какой-то степени.. Но опять же, при создании аутентификации - удобно искать пользователя по токену используя провайдер Да, пусть будет так... Просто интересно: providers: api_user_provider: id: api.user.repository можно ли так?

Что мешает реализовать простой провайдер и дать ему репозиторий как зависимость?

Кстати, возвращаясь к теме выше про ClassName::class и автолоадер, я был неправ: https://3v4l.org/s5U7V

Может так и лучше.. Спасибо за совет!

Кстати, возвращаясь к теме выше про ClassName::class и автолоадер, я был неправ: https://3v4l.org/s5U7V

То есть, видимо, единственная причина юзать строки с именем класса в Symfony - это совместимость с PHP версий ниже 5.5.

Ну это тогда просто замечательно :)

да, к примеру я всегда юзаю getRepository(User::class) вместо getRepository('AppBundle:User')

Я вдруг понял. А реально неймспейс же уже на месте есть :)

Я тоже.

Если есть вариант делать стандартно или как-то отдельно в стиле фрейма, я выбираю стандартный.

еще удобненько container->get(UserService::class) делать

А так можно кстати?

ERROR: S client not available

Он все сделает?

в 3.3 версии сервисы по FQCN регать нужно

Или конфиг в аннотациях должен быть

поэтому имя класса такое же как и айдиха

вот и умеет)

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

Но в yml все равно имя будет по старому?

в 3.3 версии сервисы по FQCN регать нужно

А как там решается вопрос, где один класс, но по-разному инициализирован?

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

Почему лучше по алиасу?

если уж про внедрение зависимостей то ->getRepository тоже лучше не делать

@Gaaarfild класс сервиса может менятся

Но в yml все равно имя будет по старому?

не. в 3.2 тоже так можно App\UserService: class: App\UserService arguments: ...

А ну я понял.

А как там решается вопрос, где один класс, но по-разному инициализирован?

другое имя сервиса даешь)

Но я имею ввиду в 3.3 уже нельзя будет как алиас писать?

можно

@Gaaarfild класс сервиса может менятся

А ты про это. :)

это и есть же алиас App\UserService

Я думал ты про AppBundle:User

не))

ктстати, написал отдельно провайдер, никакого дубляжа, все довольно таки лаконично https://pastebin.com/E97eUvhL

другое имя сервиса даешь)

Как другое, если оно по FQCN?

Как другое, если оно по FQCN?

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

Ну, то есть, алгоритм получается такой: Если сервис в единственном экземпляре - юзаем FQCN. Если нет - алиас.

угу. но вообще у меня таких сервисов можно на пальцах пересчитать

чуваки, а кто из вас с помощью capistrano деплоит симфони приложухи?

или все деплоером пользуются?

чуваки, а кто из вас с помощью capistrano деплоит симфони приложухи?

Деплоили с помощью Capifony (старая Capistrano адаптированная под Symfony), но я перевёл на Deployer.

phing, capistrano..

или все деплоером пользуются?

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

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

+1