Dans les rails, faut-il utiliser ou non des assistants de formulaire ?

Question

Dans les rails, est-il recommandé d'utiliser des assistants de formulaire ?En interne, tout se résume au simple HTML, alors pourquoi ne pas écrire le HTML directement ?Les performances seront évidemment meilleures en écrivant du HTML direct qu’en utilisant des assistants.L'utilisation des assistants de formulaire est-elle une convention ou quelque chose que les développeurs Rails doivent suivre ?

Answer 1

Définissez les performances. Votre performance ou les applications? Supposons que le même extrait de code rhtml soit disséminé dans vos vues. Disons que vous l'avez dans des milliers d'endroits. Peut-être n'avez-vous même pas obtenu exactement la même chose partout. Maintenant, votre client veut changer cela (peut-être un autre ordre de présentation). Cela vous prendra un certain temps pour le faire dans toutes les vues, non? Et les chances sont que vous ne réussirez pas du premier coup. Il y a de fortes chances que vous continuiez à recevoir des rapports de bogues pendant des années sur des endroits que vous avez manqués de changer.

Le client finira par payer beaucoup pour cette & performance " Peut-être des centaines d'heures de travail. Peut-être des dizaines de milliers si vous évitez le principe DRY par principe. Pensez à tous les serveurs et à toute la RAM qu'elle pourrait acheter pour ces heures de travail à la place. Si elle utilisait tout le matériel, son application risquait de se multiplier par cent plus rapidement. Pensez à toutes les choses amusantes avec lesquelles vous pourriez travailler au lieu de vous moquer de changer des extraits de code HTML.

Answer 2

Je pense que les aides de forme sont le reflet du principe DRY (ne vous répétez pas). Plutôt que d'écrire le même code pour effectuer des tâches similaires, la création d'un assistant de formulaire vous permettant de réutiliser ce code est la voie à suivre. Ainsi, si vous devez apporter des modifications ou des corrections, vous ne devez le faire qu’à un seul endroit. Cela permet également de rendre votre code plus compact et lisible afin de résumer une action complexe dans un assistant de formulaire. Il en va de même pour les vues partielles, bien que les vues partielles aient tendance à encapsuler des balises plus complexes qu’un assistant de formulaire.

Answer 3

Les aides de formulaire sont particulièrement utiles pour laisser des rails gérer la création de formulaires basés sur votre modèle. Pour citer l'exemple de la documentation de l'API:

Le code suivant

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

génère ce code 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>

Vous pouvez écrire le code HTML vous-même, mais en utilisant les aides de formulaire, vous devez taper moins et rendre la création de formulaire moins dépendante de l'implémentation de rails. Vous obtenez toujours un formulaire qui écrit des données dans votre modèle lorsque vous cliquez sur le bouton d'envoi. Si les développeurs de rails modifient jamais l'implémentation de cela, vous obtenez automatiquement la sortie HTML correcte de vos assistants. Si vous aviez écrit le code HTML manuellement, vous devriez tout mettre à jour pour refléter les modifications apportées au fonctionnement interne des rails.

Answer 4

Cela semble bien quand un développeur a le même nom pour la classe, l'identifiant et aucune valeur pour un champ de saisie s'il a besoin d'un identifiant de nom différent et donne également une valeur, alors il doit écrire <%= text_field_tag ​​" nom", :value=>"value", :id=>"id" ,:class=>""class %> et pour le même HTML peut être < type d'entrée ="text" value ="value" class="class" name ="name" id="id"/>pense maintenant aux frais généraux 1. évaluer le premier assistant en HTML 2. Maintenant, considérons également la longueur de celle dans l'assistant, nous devons également écrire :, =>3. parfois on oublie d'utiliser :Ou, par erreur, donc je pense que nous préférons le HTML dans ce cas et une chose si votre serveur obtient beaucoup de demande qu'il sera trop occupé et que le temps de réponse sera augmenté car <% =%> devrait devoir exécuter