1. Какие соглашения о присвоении имен мне нужно знать?
Таблица дБ - множественное число, модель - единственное число, контроллер - множественное число. Таким образом, у вас есть модель User
, которая поддерживается таблицей users
и видна через UsersController
.
файлы должны быть названы как широкая версия имени класса. поэтому класс FooBar
должен находиться в файле с именем foo_bar.rb
. Если вы используете пространства имен с модулями, пространства имен должны быть представлены папками. так что если мы говорим о Foo::Bar
классе, он должен быть в foo/bar.rb
.
2. Как должны быть структурированы и названы действия контроллера?
Действия контроллера должны быть RESTful. Это означает, что вы должны думать о своих контроллерах как о предоставлении ресурса, а не просто о включении RPC. В Rails есть концепция действий членов против действий по сбору ресурсов. Действие члена - это то, что работает с конкретным экземпляром, например, /users/1/edit
будет действием редактирования члена для пользователей. Действие сбора - это то, что действует на все ресурсы. Так что /users/search?name=foo
будет действием по сбору.
В приведенных выше руководствах описывается, как на самом деле реализовать эти идеи в файле маршрутов.
3. Каковы наилучшие способы визуализации информации в представлении (с помощью :content_for
или частичного рендеринга) и какие способы мне не следует использовать?
content_for
следует использовать, когда вы хотите иметь возможность добавлять html из внутреннего шаблона во внешний шаблон - например, возможность добавить что-то из вашего шаблона представления в шаблон макета. Хорошим примером может быть добавление javascript для конкретной страницы.
# app/views/layout/application.rb
<html>
<head>
<%= yield :head %>
...
# app/views/foobars/index.html.erb
<% content_for :head do %>
<script type='text/javascript'>
alert('zomg content_for!');
</script>
<% end %>
партиалы предназначены либо для разбивки больших файлов, либо для рендеринга одного и того же бита информации несколько раз. Например
<table>
<%= render :partial => 'foo_row', :collection => @foobars %>
</table>
# _foo_row.html.erb
<tr>
<td>
<%= foobar.name %>
</td>
</tr>
4. Что должно идти в помощник, а что нет?
в ваших шаблонах должна быть только базовая логика ветвления. Если вам нужно сделать что-то более интенсивное, это должно быть помощником. Локальные переменные в представлениях - это мерзость против всего хорошего и правильного в мире, так что это отличный знак того, что вы должны стать помощником.
Другая причина - просто повторное использование кода. Если вы делаете одно и то же с незначительными вариациями снова и снова, перетяните его в помощника (если это одно и то же, это должно быть частично).
5. Какие распространенные подводные камни или что-то, что мне нужно сделать правильно с самого начала?
partials не должен никогда напрямую ссылаться на переменные экземпляра (@), так как это предотвратит повторное использование в дальнейшем. всегда передавайте данные через параметр :locals => { :var_name => value }
в функцию рендеринга.
Держите логику подальше от ваших представлений, которая не имеет прямого отношения к отображению ваших представлений. Если у вас есть возможность сделать что-то в представлении, и сделать это где-нибудь еще, 9 раз из 10 делать это где-то еще - лучший вариант.
У нас есть мантра в рельсах, которая называется «толстые модели, тощие контроллеры». Одна из причин заключается в том, что модели являются объектно-ориентированными, а контроллеры по своей природе процедурными. Другое дело, что модели могут пересекать контроллеры, но контроллеры не могут пересекать модели. В-третьих, модели более тестируемы. Это просто хорошая идея.
6. Как вы можете модулировать код? Для этого предназначена папка lib?
папка lib предназначена для кода, который пересекает проблемы моделей (то есть того, что не является моделью, но будет использоваться несколькими моделями). Когда вам нужно что-то поместить туда, вы будете знать, потому что вы не сможете выяснить, в какую модель это вставить. Пока этого не произойдет, вы можете просто игнорировать lib.
Следует иметь в виду, что в rails 3 lib не находится на пути автозагрузки, а это означает, что вам нужно require
все, что вы туда вставили (или добавить обратно)
Способ автоматического запроса всех модулей в каталоге lib
:
#config/initializers/requires.rb
Dir[File.join(Rails.root, 'lib', '*.rb')].each do |f|
require f
end