Nano Hash - криптовалюты, майнинг, программирование

Форма ветки FOSUserBundle отправляет неожидаемое поведение

Что случилось, ребята.

Я использую PUGXMultiUserBundle поверх FOSUserBundle для регистрации и входа в систему двух разных пользовательских объектов.

Все работает из коробки: у меня есть класс User, расширяющий базовый класс User из FOSUserBundle, и две мои сущности для Seller и Customer, расширяющие класс User.

Я не хочу, чтобы мои пользователи вводили свое имя пользователя, поскольку электронная почта является предпочтительным свойством входа в систему. Поэтому в методах setEmail() и setEmailCanonical() моего класса User я также устанавливаю имя пользователя и имя пользователяCanonical вместе с электронной почтой. Это работает нормально, НО.

Проблема с твигом. Когда я визуализирую form_rest(form) в конце моей формы, она правильно отправляется, и пользователь регистрируется. Но если я попытаюсь отобразить токен безопасности с помощью form_widget(form._token) и отправить, я окажусь в той же форме, контроллер не запустится, база данных останется неизменной, ошибки не будут возвращены.

((Причина, по которой я это делаю, заключается в том, чтобы не показывать поле ввода «имя пользователя», поскольку я не требую его от своих пользователей.))

Итак, вопрос: что делает form_rest(), помимо скрытого ввода _token, что мешает моей форме работать должным образом?

Есть ли лучший подход к тому, что я пытаюсь выполнить?

Чем заранее.

forms symfony twig fosuserbundle pugxmultiuserbundle
15.01.2014

Ответы:


1

Для этого нужно сделать 2 шага:

1 Оказывается, я уже разместил первую часть вашего ответа в Удалить/Заменить поле имени пользователя на адрес электронной почты с помощью FOSUserBundle в Symfony2. Это классический способ удалить поле имени пользователя (скажем, сделать его беззвучным!) с помощью всего лишь FOSUserBundle. Выполните все шаги, указанные в этом посте.

2 При работе с PUGXMultiUserBunde необходимо выполнить дополнительную работу:

#PUGXMultiUserBundle
pugx_multi_user:
  db_driver: orm
  users:
    user_one:
        entity:
          class: Acme\UserBundle\Entity\UserOne
        registration:
          form:
            type: Acme\UserBundle\Form\Type\UserOneRegistrationFormType
            name: fos_user_registration_form
            validation_groups:  [AcmeRegistration, Default]
          template: AcmeUserBundle:Registration:registerUserOne.html.twig

    user_two:
        entity:
          class: Acme\UserBundle\Entity\UserTwo
        registration:
          form:
            type: Acme\UserBundle\Form\Type\UserTwoRegistrationFormType
            name: fos_user_registration_form
            validation_groups:  [AcmeRegistration, Default]
          template: AcmeUserBundle:Registration:registerUserTwo.html.twig

Так и должно быть!

Изменить: группы проверки

AcmeRegistration будет содержать все ограничения, которые присутствуют в FOSUserBundle для регистрации, и вы можете удалить те, которые не хотите применять (например, имя пользователя). Ограничения будут на общие поля как userOne, так и userTwo.

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

AcmeUserOneRegistration будет содержать все ограничения, относящиеся к регистрации UserOne.

AcmeUserTwoRegistration будет содержать все ограничения, относящиеся к регистрации UserTwo.

В конфигурации PUGXMultiUserBundle для userOne:

validation_groups:  [AcmeRegistration,AcmeUserOneRegistration, Default]

для пользователя Два:

validation_groups:  [AcmeRegistration,AcmeUserTwoRegistration, Default]
15.01.2014
  • Здорово! Спасибо друг! Попробую сразу после обеда. Тем не менее, пара вещей из краткого чтения: когда вы говорите «Создать файл validation.yml в Acme\UserBundle\Resources\config\config.yml», вы имеете в виду в каталоге конфигурации, верно? И еще: нужно ли мне иметь две разные группы проверки для двух разных пользовательских объектов? Я предполагаю, что да, хотя в приведенном выше примере вы используете одну и ту же группу для них двоих. Еще раз спасибо! :) 15.01.2014
  • ‹kbd›1‹/kbd›yep в конфигурационном каталоге ‹kbd›2‹/kbd›AcmeRegistration и AcmeProfile фактически заменяют то, что было сделано в FOSUserBundle, поэтому они будут использоваться для таких полей, как пароль и т. д. Если вы хотите , вы можете создать группу проверки AcmeUserOneRegistration, в которую вы добавите все ограничения, относящиеся к регистрации первого пользователя (то же самое для второго пользователя). Смотрите мою правку. 15.01.2014
  • Почти готово! Но я получаю нарушение ограничения целостности: 1048 Столбец «имя пользователя» не может быть нулевым. Думаю, я не отменяю проверки в конце концов. Достаточно ли иметь файл validations.yml в папке Resources/config моего AcmeBundle? Или он должен жить в каталоге app/Resources/config? Спасибо! 15.01.2014
  • Моя доктрина: схема: создать --dump-sql возвращает предложение CREATE TABLE с полем имени пользователя VARCHAR (255) NOT NULL, поэтому здесь что-то не так. 15.01.2014
  • Мы не удаляли поле имени пользователя, которое важно для FOSUserBUndle, мы присваиваем ему то же значение, что и адрес электронной почты (что тоже уникально). Тем не менее, мы никогда не будем использовать его, мы просто заставляем его молчать. Итак, см. пункт № 1 ответа, который я упомянул, есть установщик, который нужно изменить в вашем пользовательском объекте «setEmail». 15.01.2014
  • Мы не убрали поле имени пользователя, важное для FOSUserBUndle, мы присвоили ему то же значение, что и email (которое тоже уникально). Тем не менее, мы никогда не будем использовать его, мы просто заставляем его молчать. Итак, этот шаг является точкой nb 1 в ответ, о котором я упоминал выше... есть установщик для изменения ("setEmail") в вашем объекте пользователя, и он переопределит имя пользователя `$this-›username = $email'. 15.01.2014
  • Он установлен, но все же это вывод, который я получаю. Я даже переопределил метод setEmailCanonical, чтобы также установить имя пользователяCanonical. Странный. 15.01.2014
  • Ваш UserEntity в пакете Acme должен расширять тот, что в FOSUserBundle. Вы можете это проверить? Вы получаете простую ошибку... можете ли вы попытаться увидеть, выполняется ли ваш установщик setEmail($email) во время регистрации, поместив оператор die() или что-то еще. 16.01.2014
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..