Вопрос

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

Это было полезно?

Решение

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

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

Другие советы

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

Помощники по формам особенно полезны для того, чтобы рельсы могли создавать формы на основе вашей модели. Чтобы привести пример документации 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 вручную, вам пришлось бы обновить все это, чтобы отразить изменения внутренней работы рельсов.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top