In rails, do helper forms use or not?

Is it recommended to use form helpers on rails? Inside, it comes down to simple html, why not write html directly? Obviously, performance will be better than writing direct html than using helpers. Is the use of form helpers, for example, a convention or something that developers should follow?

+6
performance ruby-on-rails form-helpers
source share
4 answers

Determine performance. Your performance or application? Say you have the same rhtml snippet distributed according to your ideas. Say that you have it in thousands of places. You may not even have received it exactly the same in all places. Now your client wants to change this (perhaps a different presentation order or some). It will take some time to do this in every way, right? And, most likely, you will not get it right the first time. Most likely, you continue to receive bug reports for many years to find the places you missed to change.

The client will ultimately pay a lot for the resulting "performance". Perhaps hundreds of working hours. Maybe tens of thousands if you fundamentally avoid the DRY principle. Think of all the servers and all the RAM that she could buy during these hours of work. If she spent all this on hardware, her application could run a hundred times faster. Think of all the fun things you could work with instead of crippling HTML snippet changes.

+13
source share

I think that the helpers of the form are a reflection of the DRY principle (do not repeat yourself). Instead of writing the same code to perform similar tasks, creating an auxiliary form element that allows you to reuse this code, this is the way to go. Thus, if you need to make changes or fix, you only need to do it in one place. It also helps make your code more compact and readable in order to abstract the complex action into a form helper. The same applies to partial views, although partial views tend to encapsulate a more complex label than a form helper.

+4
source share

Shape assistants are especially useful to allow rails to process shapes based on your model. To give an example API documentation:

Following code

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

generates this 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> 

You can write html yourself, but with the help of the form helpers you have to enter less and make the form creation less dependent on the implementation of the rails. You always get a form that writes data to your model when you click the submit button. If rails developers ever change the implementation of this, you automatically get the correct html output from your helpers. If you wrote html manually, you will have to update all this to reflect changes in the internal operation of the rails.

+3
source share

It seems good when the developer has the same name for the class, id and no value for the input field, if he needs a different identifier for the name and also gives a value, then he should write <% = text_field_tag ​​"name",: value => " value ",: id =>" id ",: class =>" class%> and for the same html there can be <input type = "text" value = "value" class = "class" name = "name" id = "id" / "> now think over your head 1. evaluate the first helper in html 2. now also consider the length of this in the helper, we should also write :, => 3. sometimes you forgot to use: or, by mistake, therefore I think what do we prefer html in this case And oh but if your server receives many requests than it would be too busy, and the response time will be increased because <% =%> must perform

+1
source share

All Articles