How rendering works in Rails/ How helpers works in Rails

There are three ways creating http responses

  1. Call render, to create a full response that sends information back in to the browser.
  2. Call redirect_to to send http redirect states code to the browser.
  3. Call head to create a response consisting of http headers sent back to the browser

You’ll find renders being used within controllers and views… but what you’ll also notice that controllers in rails automatically render views with names that correspond to valid routes.

Example: def update

@book = Book.find(params[:id])

if @book.update(book_params)

redirect_to(@book)

else

render “edit”

end

end

There are so many ways to “customize a render, you can render default view for a rails template, or a specific template, or a file, or inline code, or nothing at all.”

“You can render text, JSON, or XML and specify the content type or http sttus of the rendered response. JSON is a js data formula used by many AJAX libraries. Rails already has the means and tools to handle and support JSON and converting objects into JSON and rendering JSON right back into the browser.

Example:

render json: @ product

You can also render regular JavaScript and raw body HTML.

“Another way to handle return responses to an http request is to redirect_to”

The two aren’t the same… “render tells rails which view (or other asset) to use in constricting response.”

“The redirect_to tells the browser to send a new request for a different url”

Example: redirect_to :index or redirect_back

Next up are form helpers

“The most basic form helper is form_tag.

<%= form_tag do %>

Form contents

<% end %>

One of the most basic forms you see on the web is a search form. This form contains:

  • a form element with “GET” method,
  • a label for the input,
  • a text input element, and
  • a submit element.

To create this form you will use form_tag, label_tag, text_field_tag, and submit_tag, respectively. Like this:

<%= form_tag(“/search”, method: “get”) do %>

<%= label_tag(:q, “Search for:”) %>

<%= text_field_tag(:q) %>

<%= submit_tag(“Search”) %>

<% end %>

This will generate the following HTML:

<form accept-charset=”UTF-8" action=”/search” method=”get”>

<input name=”utf8" type=”hidden” value=”&#x2713;” />

<label for=”q”>Search for:</label>

<input id=”q” name=”q” type=”text” />

<input name=”commit” type=”submit” value=”Search” />

</form>”

The form_tag helper acknowledges two arguments, one “the path for the action and an options hash. This hash specifies the method of form submission and HTML options such as the form element’s class.”

A link_to is also considered a helper, so is a radio_button, check_box, text_area, search_field, and much more. This helpers exist within the view of a Rails framework.

Model Object Helpers

“A particularly common task for a form is editing or creating a model object. While the *_tag helpers can certainly be used for this task they are somewhat verbose as for each tag you would have to ensure the correct parameter name is used and set the default value of the input appropriately. Rails provides helpers tailored to this task. These helpers lack the _tag suffix, for example text_field, text_area.”

Example: <%= text_field(:person, :name) %>

will produce output similar to

<input id=”person_name” name=”person[name]” type=”text” value=”Henry”/>

http://guides.rubyonrails.org/form_helpers.html

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.