Лучшие практики для статических страниц в приложении rails

Question

Я занимаюсь разработкой приложения на ruby ​​on rails для местного бизнеса. Страницы "статичны", но их можно изменить с помощью внутренней CMS, которую я создаю для них. Есть ли лучшая практика для создания контроллера для статических страниц? Прямо сейчас у меня есть контроллер сайтов со всеми статическими маршрутами, как это.

routes.rb

get "site/home"
get "site/about_us"
get "site/faq"
get "site/discounts"
get "site/services"
get "site/contact_us"
get "site/admin"
get "site/posts"

или было бы лучше, если бы я создавал маршруты участников для контроллера сайта без всяких проблем, потому что "сайту" не нужно иметь CRUD.

resources :sites, :except => [:index, :new, :create, :update, :destroy]
member do
  get :home
  get :about_us
  get :faq
  get :discounts
  get :services
  get :contact_us
  get :admin
  get :posts
end

Или есть лучшая практика / лучший способ? Любые ответы будут оценены. Спасибо

Answer 1

Если список статических страниц не будет увеличиваться, вы можете сохранить этот список, но если вы хотите динамический список, такой как site/any_new_url, сохраните маршруты как

get 'site/:cms_page' => 'cms#show' # all requests matching site/any_page will go CmsController, show method

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

def show
  @page_data = Page.find_by_page(:params[:cms_page])
end

show.html.erb

<%= @page_data.html_safe %>

Answer 2

Не знаю пока, считаю ли я это лучшей практикой или мерзостью, но вот что я придумал, решая ту же проблему.

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

class Organisation < ActiveRecord::Base

  ...validations stuff...

  def self.attrs_regex
    Regexp.new(self.attrs.join("|"))
  end

  def self.attrs
    self.column_names.reject{|name| name =~ /id|created_at|updated_at/}
  end

end

Затем я использую метод класса attrs для генерации маршрутов на основе столбцов. Это в моих маршрутах.rb:

Organisation.attrs.each do |attr|
  get "#{attr}" => "organisation##{attr}", :as => attr.to_sym
  get "#{attr}/edit" => "organisation#edit", :as => "#{attr}_edit".to_sym, :defaults => { :attribute => attr }
  post "#{attr}" => "organisation#update", :as => :organisation_update, :defaults => { :attribute => attr}, :constraints => Organisation.attrs_regex
end

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

class ApplicationController < ActionController::Base
  protect_from_forgery
  before_filter :set_attribute

  def set_attribute
    @attribute = action_name.parameterize
  end

end

Для контроллера организации я просто установил переменную @organisation в качестве первой и единственной строки в базе данных в before_filter, а затем позволил Rails выполнять свою обычную магию: вызывать метод, давать сбой и отображать представление с тем же именем. Действие edit просто использует один файл представления для редактирования всех различных атрибутов:

class OrganisationController < ApplicationController


  before_filter :set_organisation

  def edit
    authorize! :edit, @organisation
    @attribute = params[:attribute].parameterize
  end

  def update
    authorize! :update, @organisation
    @attribute = params[:attribute]
    respond_to do |format|
      if @organisation.update_attributes(params[:organisation])
        format.html do 
          redirect_to "/#{@attribute}", notice: t('successful_update')
        end
        format.json { head :ok }
      else
        format.html { render action: "edit" }
      end
    end
  end

  private

  def set_organisation
    @organisation = Organisation.first
  end

end

Вот где я и оказался. Как и вы, я наткнулся на SO, чтобы воспользоваться кипящей гениальной массой, но в итоге получился неутешительный результат. Если есть что-то лучшее, я все еще надеюсь найти это.

Что мне нравится в том, что я сделал, так это то, что маршруты автоматически генерируются на основе структуры организационной таблицы.

Что мне не нравится в том, что я сделал, так это то, что маршруты автоматически генерируются на основе структуры организационной таблицы.

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

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

Answer 3

Если вы собираетесь создать CMS, которая, вероятно, подключается к базе данных и позволяет вашему клиенту изменять текст на страницах своего сайта, я бы не рекомендовал использовать статические страницы. В терминах Rails под статической страницей подразумевается создание html-файлов в каталоге /views/pages. Если вы идете по этому пути, то вы идете за пределы того, что было разработано Rails.

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

Что касается маршрутов, я бы рекомендовал использовать следующее:

map.resource :controller_name

Затем вы добавили бы код, который отображает информацию из CMS в соответствующем действии show controller и просмотра для каждой страницы.