Борьба с отношением один ко многим в форме администратора - PullRequest
Новая
       6

Борьба с отношением один ко многим в форме администратора

2 голосов
/ 22 апреля 2011

Я прошу прощения, если ответ на мой вопрос будет очень очевидным. Я новичок в Symfony, и мне не удалось найти другой вопрос с точно такой же проблемой, как у меня в SO, поэтому я отправляю вопрос. (И Google тоже не сильно помог, но, опять же, я не очень знаком с терминологией Symfony, поэтому мог бы плохо сформулировать свои запросы.)

Итак, прямо к делу. schema.yml : 

user:
  id:
  email:   { type: varchar, size: 255, required: true }
  ... # etc.

partner:
  user_id: { type: integer, foreignTable: user, foreignReference: id }

(Кстати, используя Symfony 1.3 и Propel 1.4).

Итак, у меня сгенерированы методы $ user-> getPartners () и $ partner-> getUserId () (хотя я где-то читал, что если ваш FK - это PK в Согласно ссылочной таблице, Propel навязывает отношения один-к-одному, но я наблюдаю отношения один-ко-многим, если я не понял это очень неправильно). Хорошо. Тем не менее, у меня есть модуль администратора для редактирования пользователя, и в настоящий момент я пытаюсь понять, как именно я должен заставить Symfony отображать список партнеров с несколькими вариантами выбора в форме «Пользователь / редактирование» (двойной список был бы хорош тоже).

Попытка поместить "partners" и "partner_list" в apps / backend / modules / user / generator.yml (где я успешно добавил логическое значение и статический выбор [через * Peer :: getXXXChoices () ] уже), только для получения ошибок "Виджет" партнеры "не существует".

Полагаю, я мог бы отредактировать класс формы, но я понятия не имею, как сказать Propel, чтобы он формировал визуальное отношение «один ко многим», используя «множественный = true», потому что «выборы» не являются статическими; это зависит от другой таблицы.

Так как мне это сделать? Не стесняйтесь спрашивать дополнительные детали, если я опущу что-то важное.

Привет.

1 Ответ

1 голос
/ 23 апреля 2011

Я однажды сталкивался с той же проблемой, так что это мое решение проблемы.Symfony не очень умен в таких ситуациях, поэтому вам нужно немного помочь.Модель, которую вы описываете, идеально подходит для интерпретации проблемы с помощью реляционной модели: 

user:
  id:
  email:   { type: varchar, size: 255, required: true }
  ... # etc.

partner:
  user_id: { type: integer, foreignTable: user, foreignReference: id }

Дело в том, что Symfony действительно упрощает ее, а когда Propel генерирует формы и анализирует формы для передачи данных для сохранения данных, он интерпретирует user_idполе, как если бы это было какое-то нормальное поле (не однозначным).

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

user:
  id:
  email:   { type: varchar, size: 255, required: true }
  ... # etc.

partner:
  user_id: { type: integer, foreignTable: user, foreignReference: id }

user_partner:
  user_id: { type: integer , foreignTable: user, foreignReference: id, primaryKey: true}
  partner_id: { type: integer , foreignTable: partner, foreignReference: id, primaryKey: true}

Таким образом у вас будет виджет partner_list в пользовательской форме, а также виджет user_list в партнерской форме.Я всегда отключаю тот, который мне не нужен, и действительно работает как шарм.

Другие решения, которые лучше всего подходят для реализации вашей модели, немного сложнее, потому что вам нужно изменить пользовательскую форму и добавитьМногоэлементный виджет partner_ids затем модифицирует метод doSave, чтобы иметь возможность обрабатывать логику сохранения множественного выбора (создавать экземпляры, связывать их с пользователем и сохранять их, а также удалять невыбранные).

...