在rails中,是否建议使用表单助手?在内部,一切都归结为普通的html然后为什么不直接写html?在编写直接html时,性能显然比使用帮助程序更好。是否使用了类似于约定的表单助手或者铁轨开发人员必须遵循的东西?
答案 0 :(得分:13)
定义表现。您的表现或申请?假设您在视图中分布了相同的rhtml代码段。假设你在成千上万的地方拥有它。也许你甚至没有在所有地方都完全相同。现在您的客户希望改变这种情况(可能是不同的演示顺序或其他类似情况)。在所有观点中你都需要一段时间才能做到这一点,对吧?你第一次有可能无法做到正确。实际上,您可能会在未来几年内收到错误报告的错误报告。
客户最终会因为获得“性能”而付出很多。也许数百个工作小时。如果你原则上避免DRY原则,可能会成千上万。想想所有服务器以及她可以为这些工作时间购买的所有RAM。如果她把所有这些花在硬件上,她的应用程序可能会快一百倍。想想你可以使用的所有有趣的事情,而不是改变html片段。
答案 1 :(得分:4)
我认为表格助手是DRY(不要重复自己)原则的反映。而不是编写相同的代码来执行类似的任务,创建一个允许您重用该代码的表单帮助程序是要走的路。这样,如果您需要进行更改或修复,您只需要在一个地方进行更改或修复。它还有助于使代码更加紧凑和可读,从而将复杂的操作抽象为表单助手。部分视图也是如此,尽管部分视图倾向于封装比表单助手更复杂的标记。
答案 2 :(得分:3)
表单助手对于让rails根据您的模型处理创建表单特别有用。引用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,但是通过使用表单助手,您必须输入less并使表单创建更少依赖于rails实现。当您点击提交按钮时,总会得到一个将数据写入模型的表单。如果rails开发人员改变了这个的实现,你会自动从你的帮助器中获得正确的html输出。如果您手动编写了html,则必须更新所有内容以反映rails内部工作的变化。
答案 3 :(得分:1)
如果开发人员对于输入字段具有相同的类名,id并且没有输入字段的值,如果他需要不同的名称id并且还给出值,那么它似乎很好,那么他必须写&lt;%= text_field_tag“name”, :value =&gt;“value”,:id =&gt;“id”,:class =&gt;“”class%&gt; ,对于相同的html,可以是&lt; input type =“text”value =“value”class =“class”name =“name”id =“id”/&gt; 现在认为开销 1。将第一个助手评估为html 2。现在还要考虑助手的长度,我们还要写:,=&gt; 3。有时你会忘记使用:或者,错误地使用 所以我认为在这种情况下我们更喜欢html 有一件事,如果您的服务器收到大量请求而不会太忙,响应时间会增加,因为&lt;%=%&gt;应该执行
答案 4 :(得分:0)
这是一个非常老的问题,但是我是个新手。我会争辩说,而不是写这个
<label class="input-group__label" for="email">Email</label>
<input class="input-group__field" id="email" type="email" name="email" placeholder="e.g. me@something.com">
用这样的Rails助手写同样的东西
<%= label_tag 'email', nil, class: 'input-group__label' %>
<%= email_field_tag "email", nil, placeholder: "e.g. me@something.com", class: "input-group__field" %>
form_tag
中的是一种非常干燥的处理方式。
在第一个中,可读性更好。
每个人都可以理解。不需要Rails知识。
不评估和转换Rails特定的标签(性能略有提高)。
代码量是相同的。
如果那是在form_for
里面,它可以通过模型创建表单,那么我了解Rails特定标签和帮助程序的用法。这说得通。但是我没有看到像上面的示例那样将rails helper用于简单的html的真正优势。