Ruby on Rails 3 validation model

Question

[paxer]

Предположим у нас есть User модель и в ней есть first_name, last_name, email поля. Все они обязательные. Соотвественно в модели мы прописываем
что-то типа такого

validates :first_name, :presence => true
validates :last_name, :presence => true
validates :email, :presence => true

и все было бы хорошо если бы форма была на одной странице.
А теперь вопрос, как поступть с validation если форма для апдейта first_name и last_name на одной странице а email на другой.
По умолчанию так сказать на форме где first_name и last_name если ее засабмитеть то будет ошибка что мол email требуется и это верно (у меня же email на другой странице нужно обновлять), тоже самое и на форме email где валидация будет просить first_name и last_name. Меня интересует как в Rails 3 корректно обрабатывать такую ситуацию.

К примеру в ASP.NET MVC я делаю как бы child ViewModel непосредственно для конкретного View проверяю поля и потом делаю маппинг свойств с родительской моделью. Как правильно это сделать в Rails 3?

Answer 1

[kirsan_vlz]

Если я правильно понял ваш алгоритм, то сначала у вас создаётся запись с first_name и last_name, а потом уже в существующей записи обновляется поле email.
Тогда попробуйте
validates :first_name, :presence => true
validates :last_name, :presence => true
validates :email, :presence => true :on => :update
И при добавлении поля email загружать уже существующий объект.
Тогда на первой форме у вас будет будут проверяться первые два поля, вы сохраните объект.
Потом, на второй форме, вы загрузите объект с уже заполненными полями first_name и last_name, и обновите его. А при обновлении сработает валидация на поле email.

Comments

[paxer]

спасибо, уже понятней, однако, предполложим я создал объект, теперь я захожу на страницу где у меня first_name и last_name и хочу обновить first_name. В этом случае идет update и модель ругнется что требуется email и как бы верно, но форма update email у меня на другой странице. То есть мне нужно чтобы модель ругалась про требование email только на той форме (отдельной странице от редактирования first_name и last_name. Я поэтому и привел пример с ASP.NET MVC что там в данной ситуации содают ViewModel, как бы микро модель для конкретного View и делают валидацию непосредственно полей View а не всей текущей модели (в нашем случае User) а потом замапивают свойства (поля) ViewModel c Business Model (User). Я полагаю что у Рельсов должно быть что то подобное. В любом случае ваша подсказка с on => update уже сильно облегчает ситуацию.

[paxer]

судя по всему, то что мне нужно, это Presenter Pattern blog.jayfields.com/2007/03/rails-presenter-pattern.html? Или все-же есть другое красивое решение?

Answer 2

[mpetrunin]

Немного устаревший, но позволяющий понять, принцип railscast на эту тему: railscasts.com/episodes/217-multistep-forms

Comments

[kirsan_vlz]

Там, в принципе, особо устаревшего нет.
:if для валидаторов в третьей версии всё также актуален, сессии также работают.

Answer 3

[Георгий Хромченко]

Я делал state_machine и валидаторы в зависимости от state

В примере на github.com прямо показано, как такое делать

state :first_gear, :second_gear do
validates_presence_of :seatbelt_on
end

Answer 4

[Антон Дьячук]

средствами чистого Rails в рабочей системе

with_options :if => «cause == 1» do |client|
client.validates :prepay, :cost, :birthday, :phone1, :contract_date, :vin, :adress, :presence => 'true'
client.validates_presence_of :id_series, :id_number, :id_dep
client.validates_format_of :id_series, :id_number, :with => /[\d\s]/
client.validates_presence_of :fio
client.validates :car, :presence => true
end

with_options :if => 'cause == 5' do |client|
client.validates_presence_of :fio, :manager, :trade_in_price, :trade_in_desc
client.validates_associated :used_car

end

Answer 5

[Silaev]

Условия это зло. Модель от этого неимоверно разрастется. Намного проще сделать новый уровень абстракции в приложении и назвать его, например, types. Итак, создаем два типа пользователя:
UserRegisterType < User и UserEmailSetterType < User(названия придумйте сами). Теперь, в контексте этих унаследованных моделей можно проставить нужные нам attr_accessible, validates, и прочие штуки. Более подробно о данном решении и подводных камнях можно почитать в блоге Кирилла Мокевнина