Rails 3, большая многошаговая форма: 1 большой контроллер или разделенный ресурсом?

Question

У меня есть многошаговая форма, где пользователь заполняет информацию на нескольких разных страницах. В обычных rails вы храните каждый ресурс отдельно в своем контроллере и используете действия REST для манипулирования данными.

В обычной системе у меня было бы 3-5 различных контроллеров (некоторые шаги необязательны) для одной многошаговой формы. Там нет реального смысла "порядок" в контроллерах, если я делаю это обычным способом. Новый разработчик, участвующий в проекте, должен узнать, какие шаги соответствуют каким шагам и так далее.

С другой стороны, я думал о нарушении соглашения и единого контроллера, который организует всю многошаговую форму. Этот контроллер будет полон методов, таких как:

def personal_info
  # code...
end

def person_info_update
  # code...
end

def residence_info
  # code...
end

def residence_info_update
  # code...
end

# many more coupled methods like the above...

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

Это нарушило бы соглашение о рельсах, и мне пришлось бы настроить собственную маршрутизацию.

Но мне любопытно, как другие решили эту проблему? Я знаю, что МОЖЕТ работать, но я хотел бы знать, что легче поддерживать и кодировать в долгосрочной перспективе.

Answer 1

Ресурс не равен странице. Я подозреваю, что оба способа нарушили бы ограничение на REST.

Все ваши интересы связаны с доменом View, который находится в вашем браузере. Если вы хотите отобразить одну форму из нескольких частей, вы должны сделать это, используя HTML, CSS и т. Д.

В противном случае вы просто создаете временное хранилище на своих серверах для продвижения форм.

Answer 2

Я сделал что-то подобное с https://github.com/pluginaweek/state_machine

Идея состояла в том, чтобы иметь одно состояние на шаг формы и просто визуализировать частичную форму в зависимости от того, какое состояние имеет реальный ресурс. Вышеуказанная жемчужина позволяет указать валидации и обратные вызовы для каждого состояния.

Таким образом, вы можете использовать стандартные действия контроллера REST.