Комментарии 12
Извиняюсь, но не совсем понял:
Экземпляр Company все равно будет создаваться явным образом в контроллере, чтобы использоваться в форме. Какую выгоду мы получаем, маскируя явное создание ассоциированных моделей с помощью гема?
Экономия одной строки кода — несколько сомнительная выгода))
Экземпляр Company все равно будет создаваться явным образом в контроллере, чтобы использоваться в форме. Какую выгоду мы получаем, маскируя явное создание ассоциированных моделей с помощью гема?
Экономия одной строки кода — несколько сомнительная выгода))
+1
Если ассоциаций несколько, то не одну, а если форм много можно избавиться от целой кучи строк «говнокода». Также, если использовать гем inherited_resources, это избавляет от говнокода в контроллерах вовсе, т.е. получаем в контроллере только его определение (2 строки кода), к чему, я считаю, должны стремиться всегда разработчики rails.
0
Стремиться надо к понятному и читаемому коду, в котором с первого взгляда понятно что откуда берется, а не к экономии строк кода. Поповоду inherited_resources он годен только для стандартных CRUD админок, а как только в сторону от этого отойдешь так он превращает разработку в ад.
-1
Если в контроллере куча методов не CRUD, это говорит только о непродуманной архитектуре проекта
+1
1. Не все можно описать CRUD-ом.
Вот тут github.com/plataformatec/devise/blob/master/app/controllers/devise/omniauth_callbacks_controller.rb, например, вообще нет ни одного CRUD метода.
2. 5 минут покопавшись нашел HomeController с двумя методами index для все, и 'другой_index' для партнеров. Городить ради этого что-то большее, чем неCRUD я не собираюсь.
3. Вспомогательная информация для front-end, когда ее много и разной не делается CRUD-ом.
Вот тут github.com/plataformatec/devise/blob/master/app/controllers/devise/omniauth_callbacks_controller.rb, например, вообще нет ни одного CRUD метода.
2. 5 минут покопавшись нашел HomeController с двумя методами index для все, и 'другой_index' для партнеров. Городить ради этого что-то большее, чем неCRUD я не собираюсь.
3. Вспомогательная информация для front-end, когда ее много и разной не делается CRUD-ом.
0
Ну вот если взять страницы вроде /tos /contacts /about ит.д, иными словами не то, что НЕ Restful, но и по сути своей полу-статические (информация на них обновляется крайне и крайне редко).
Городить специальный Ресурс для них и получить результат формата yourdomain/pages/about?
Ну не знаю не знаю…
Городить специальный Ресурс для них и получить результат формата yourdomain/pages/about?
Ну не знаю не знаю…
0
Вот, рекомендую это посмотреть на этот случай railscasts.com/episodes/117-semi-static-pages-revised
0
Видимо Вы незнаете, что можно сделать и это в RESTful стиле
get "pages/:page" => "pages#show"
class PagesController < ApplicationController
rescue_from ActionView::MissingTemplate, :with => :page_not_found
def show
render CGI.escape(params[:page])
end
end
0
Возможно я что-то не так понял, но в предлагаемом вами варианте необходимо прописать 7 строк в routes.rb для создания RESTful resource и отлавливать исключения в Контроллере на случай если страница не найдена?
0
В routes.rb прописана одна строка:
slayerhabr, отличный код! Спасибо!
get "pages/:page" => "pages#show"
и ее достаточно для того, чтобы отлавливать все запросы вида pages/blablabla. Отлавливает их контроллер PagesController, как не трудно догадаться. И, поразительно, что кода в этом контроллере тоже достаточно, чтобы разруливать ситуации, когда запрос нормальный и ответ может быть адекватно обработан (соответствующая запросу страница в шаблонах имеется) и когда запрос пришел< а шаблона нет. slayerhabr, отличный код! Спасибо!
0
посмотрите внимательней:
в routes.rb — одна строка, самая первая
обработка исключений — одна строка (rescue_from)
в routes.rb — одна строка, самая первая
обработка исключений — одна строка (rescue_from)
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Автоматическое создание объекта ассоциаций has_one и belongs_to