Лучшая практика Rails для получения одинаковой формы на нескольких страницах

Question

Я разрабатываю веб-сайт Rails 2.3.1. На протяжении всего веб-сайта мне нужно иметь форму для создания сообщений на разных страницах (страница «Домашняя страница», «Создать сообщения», «Страница« Список публикаций »,« Страница комментариев »и т. Д.), Достаточно, чтобы заявить, что эта форма должна быть на многих страницах, обслуживаемых различные контроллеры). На каждой из этих страниц отображается большое количество другой информации, которая извлекается в соответствующем контроллере/действии. Например, на главной странице перечислены последние 10 сообщений, содержимое выведено из БД и т. Д.

Итак, я переместил форму создания Post в ее собственную частичную часть и включил это частичное на все необходимые страницы. Обратите внимание, что форма в Частичных POSTs/Вопросы (которые направляются на PostsController :: create - это поведение по умолчанию rails).

Проблема, с которой я столкнулся, - это когда форма сообщений заполнена неправильно, по умолчанию заданы вопросы PostsController :: create method render/new.html.erb, даже если форма была отправлена ​​с домашней страницы (/ главная/index.html.erb).

Я попытался изменить форму в частичном представлении «подчиняющего_контроллера» и «подчинения_имен», а в PostsController :: create, когда @ post.save? == false, я выношу action => "../submitting_controller/submitting_action" (что немного взломанно, но позволяет отображать действия из не-PostsController).

Это, казалось, работало нормально на поверхности. Неполная форма была отображена в представлении, которое отправило его со всем правильным сообщением @ post.errors и т. Д. Проблема была ВСЕ, другие данные на страницах не отображались, потому что фактические методы отправки_controller/submitting_action не вызывались, просто соответствующий вид. (Remeber, я сделал рендер, который сохраняет объекты экземпляра, а не redirect_to, который не сохраняет объект экземпляра @post, который имеет все сообщения об ошибках и представленные значения.)

Насколько я вижу, у меня есть два варианта :

1) Я могу хранить объект @post в сеансе, когда @ post.save? fail в PostsController :: create, redirect_to submitting_controller/submitting_action, после чего я вытаскиваю объект @post из сеанса и использую его для повторного заполнения сообщений формы/ошибки. (Насколько я понимаю, хранение объектов в сеансе является практикой BAD в рельсах)

2) Я могу переместить всю логику, используемую для вытягивания данных формы, отличных от поста, от различных подчиняющихся_controller/submitting_action, поместив их в ApplicationController, создайте гигантский оператор switch в PostsController :: create for submitting_controller/submitting_action и вызовите методы в ApplicationController, чтобы захватить все дополнительные данные, необходимые для каждого рендеринга страницы отправки.

Мысли о лучшем способе сделать это в Rails?

Answer 1

Возможно, ваша модель Post связана с каждой моделью, которую вы будете использовать для визуализации вашей формы? Выполняете ли вы специальную обработку в контроллере Post за пределами Post.create(params[:post])?

Если вы ответили «да» на первый вопрос, а не на второй, вы можете пройти с минимальным управлением, добавив accepts_nested_attributes_for для каждого из контроллеров, на которых пользователь может создать сообщение.

Независимо от этого, Robertpostill верен тем, что это, вероятно, когда следует взглянуть на AJAX, чтобы просто заменить раздел страницы. Единственная проблема заключается в том, что делать, если пользователь отключил javascript. Лично мне нравится делать дизайн для случая, отличного от javascript, и добавлять удобные методы.

Что касается мыслей о том, какие вы считаете ваши два варианта,

1) Я использовал этот метод, чтобы сохранить неполную копию объекта в флэш-хэш. Сохранение его через перенаправления. Однако это может не сработать для вас, учитывая переменный характер сообщений. Поскольку вы можете отправлять только данные объемом около 4 тыс., И это включает в себя другую информацию в дополнение к вашей мелкой копии.

2) См robertpostill в ответ

Answer 2

Речь идет о том, что вы переходите от полностраничных обновлений к обновлению разделов страницы с помощью AJAX. Есть куча вещей, которые вы должны учитывать, но наиболее рациональный подход - это разделить ответ между ответом AJAX и простым ответом HTML. Выезд this ONLamp article, this register article или the awesome agile web development with rails book. По существу ваш контроллер отображает новый div, заменяющий старый div, содержащий результат отправки частичного.

В своем вопросе вы упомянули два подхода, и поэтому я постараюсь дать вам несколько советов о том, почему и почему не здесь:

Вариант 1) вариант Ths не так уж плохо с парой ухищрений. Основной настройкой является сохранение объекта в сериализованной форме в БД. Затем просто пропустите идентификатор сериализованного объекта.Ваши преимущества в том, что данные сеанса сохраняются, поэтому восстановление сеанса более аккуратное, и ваш сеанс остается светлым. Недостатком этого является то, что наличие ведро сеанса в вашей БД будет загрязнять ваше приложение, и вам нужно подумать о том, как вы истекаете неиспользуемый сеансовый треск из БД. Я никогда не видел этот конец хорошо ...

Option2) Eeek не внутри application_controller! :) Серьезно, держи это, как твое оружие последней инстанции. Вы можете всплывать все, кроме помощников, и получать доступ к этим методам внутри ваших контроллеров и представлений. Однако тестирование этого материала не так просто, поэтому будьте осторожны, прежде чем выбирать этот маршрут. Операторы Switch могут быть заменены в приложениях OO небольшим количеством мышления, конечно, в его случае вы можете использовать хэш-опции, чтобы получить рельефный способ иметь некоторые умения о состоянии приложения во время запроса.