В рельсах, использовать ли помощники формы или нет? - PullRequest
6 голосов
/ 10 января 2009

В рельсах рекомендуется использовать помощники формы? Внутренне все сводится к простому html, тогда почему бы не написать html напрямую? Производительность, очевидно, будет лучше при написании прямых HTML, чем при использовании помощников. Является ли использование помощников форм чем-то вроде соглашения или того, что разработчики рельсов должны соблюдать?

Ответы [ 4 ]

13 голосов
/ 10 января 2009

Определить производительность. Ваша производительность или приложения? Скажем, у вас есть один и тот же фрагмент кода rhtml, разбросанный по вашим представлениям. Скажем, у вас есть это в тысячах мест. Может быть, вы даже не получили это точно одинаково во всех местах. Теперь ваш клиент хочет изменить это (возможно, другой порядок презентации или что-то подобное). Вам понадобится время, чтобы сделать это во всех видах, верно? И скорее всего, вы не поймете это правильно с первого раза. Скорее всего, в течение многих лет вы будете получать отчеты об ошибках в местах, которые вы пропустили, чтобы измениться.

Клиент в конечном итоге заплатит много за полученную «производительность». Может быть, сотни рабочих часов. Может быть, десятки тысяч, если вы будете избегать принципа СУХОЙ в принципе. Подумайте обо всех серверах и всей оперативной памяти, которую она могла бы купить вместо этих рабочих часов. Если бы она потратила все это на оборудование, ее приложение могло бы работать в сотни раз быстрее. Подумайте обо всех забавных вещах, с которыми вы могли бы работать, вместо того, чтобы переключаться между изменениями фрагментов HTML.

4 голосов
/ 10 января 2009

Я думаю, что помощники по формам являются отражением принципа СУХОЙ (не повторяйся). Вместо того, чтобы писать один и тот же код для выполнения похожих задач, создание помощника по форме, позволяющего вам повторно использовать этот код, - это путь. Таким образом, если вам нужно внести изменения или исправить, вам нужно сделать это только в одном месте. Это также помогает сделать ваш код более компактным и читаемым, превращая сложное действие в помощник по форме. То же самое относится и к частичным представлениям, хотя частичные представления имеют тенденцию инкапсулировать более сложную разметку, чем помощник формы.

3 голосов
/ 10 января 2009

Помощники по формам особенно полезны для того, чтобы рельсы могли создавать формы на основе вашей модели. Чтобы привести пример документации API:

следующий код

<% form_for :person, @person, :url => { :action => "create" } do |f| %>
  <%= f.text_field :first_name %>
  <%= f.text_field :last_name %>
  <%= submit_tag 'Create' %>
<% end %>

генерирует этот HTML

<form action="/persons/create" method="post">
  <input id="person_first_name" name="person[first_name]" size="30" type="text" />
  <input id="person_last_name" name="person[last_name]" size="30" type="text" />
  <input name="commit" type="submit" value="Create" />
</form>

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

1 голос
/ 18 мая 2012

Кажется хорошим, когда разработчик, имеющий одно и то же имя для класса, идентификатор и не имеющий значения для поля ввода, если ему нужно другое имя, но также и значение, должен написать <% = text_field_tag ​​"name",: value => "value",: id => "id",: class => "" class%> и для того же html может быть теперь подумайте над издержками 1. вычислите первый помощник в html 2. , теперь также рассмотрим длину, которую в помощнике мы также должны написать:, => 3. иногда вы забываете использовать: или по ошибке так что я думаю, что мы предпочитаем HTML в этом случае И еще одна вещь, если ваш сервер получает много запросов, чем он будет слишком занят, и время отклика будет увеличено, потому что <% =%> должен будет выполнить

...