Rails: Как обрабатывать некоторые поля информации о модели независимо? Например. Информация об аккаунте и профиле - PullRequest
2 голосов
/ 24 февраля 2010

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

Например, я хотел бы иметь Name, Bio и Location для редактирования на странице или вкладке Profile, а также login, email и password для редактирования. на странице или вкладке Account.

Каковы наилучшие методы и самый безопасный способ для этого? Должен ли я иметь две отдельные модели / ресурсы: User и UserProfile? Или я могу просто создать что-то вроде profile метода в UserController, с пользовательской формой, содержащей только определенные поля профиля, и ссылаться на нее на странице пользователя? Я действительно запутался в том, как это сделать.

Заранее благодарим вас за любые идеи, которые у вас могут быть.

Ответы [ 3 ]

3 голосов
/ 24 февраля 2010

Я думаю, это зависит от остальной части вашего приложения. Похоже, в вашем случае хорошо быть модульным. Если вы хотите, чтобы пользователи могли видеть профиль других пользователей, то преимуществом является наличие отдельной модели для профиля и привязки к ней с отношением has_one. Я бы просто назвал класс Profile, чтобы к нему можно было получить доступ через user.profile в ваших контроллерах и представлениях.

Модель:

class User < ActiveRecord::Base
  has_one :profile, :dependent => :destroy
end

class Profile < ActiveRecord::Base
  belongs_to :user
end
3 голосов
/ 24 февраля 2010

Если у всех ваших пользователей есть поля профиля и учетной записи, я бы не стал указывать это в отдельных моделях. Это только добавит ненужную сложность вашим формам, а добавление может добавить некоторые sql запросы.

Я не вижу здесь никаких проблем с безопасностью. В случае редактирования оба действия (редактирование аккаунта и профиля) должны быть защищены одинаково - так что только владелец-пользователь должен иметь возможность редактировать их оба. Если он хочет «взломать» его и отредактировать также свой логин, когда редактирует свое имя, тогда это его проблема. Это не вызовет никаких проблем, так как ему разрешено редактировать оба поля.

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

Как это отделить? Для меня самый чистый способ - добавить такие маршруты:

map.resources :accounts
map.resources :profiles

И используйте пути типа /accounts/34/edit для редактирования части учетной записи и /profiles/34/edit для редактирования части профиля.

В этом случае вам понадобится отдельный контроллер для обоих маршрутов: accounts_controller.rb и profiles_controller.rb. Если у них много похожих методов и поведения, вы можете добавить его в users_controller.rb, а также в профили и контроллеры учетных записей, наследующие его.

Вы также можете сделать это с одним контроллером:

map.resources :accounts, :controller => 'users'
map.resources :profiles, :controller => 'users'

Но я не знаю, как передать какое-то дополнительное значение для маршрутов, созданных с помощью resources. Когда вы используете connect, вы можете передать его с :defaults => {:foo => 'bar'}, и тогда он будет доступен в контроллере как params[:foo], но, похоже, он не будет работать с resources. Так как же отличить аккаунты от профилей? Вы можете прочитать его по текущему URL ( вот пример ). И тогда в контроллере вы можете визуализировать различные представления в соответствии с запрашиваемым ресурсом.

1 голос
/ 24 февраля 2010

Я был бы склонен резать вдоль зерна здесь. Будет проще сопоставить модель с формой. Поэтому, если у вас есть информация, доступ к которой осуществляется в различных формах вашего пользовательского интерфейса, я бы создал модель для каждого из них.

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

...