Rapid Prototyping with Ruby on Rails - Week 2 Quiz

gistfile1.txt

Week 2 Quiz

1. Name all the 7 ( or 8) routes exposed by the 'resources' keyword in the routes.rb file. Also name    
the named routes, and how the request is routed to the controller/action.

    	routes: if the application has a controller called Posts for example, the router matches 
    	HTTP Verb and URL of an inbound request to different actions in 	the controller.

	    HTTP Verb		Path(URL)		Action		Used for
	    GET			/posts			index		displays the list of all posts
	    GET		    	/posts/new	    	new		returns an HTML form for creating a new post
	    POST		/posts			create		create a new post
	    GET			/posts/:id		show		show a specific post
	    GET		    	/posts/:id/edit		edit		return a HTML form for editing a post
	    PATCH		/posts/:id		update	  	update a specific post
	    PUT			/posts/:id		update	  	update a specific post
	    DELETE		/posts/:id		destroy	  	delete a specific post

   The named routes:
  	posts_path		returns /posts
  	new_post_path	        returns /posts/new
	edit_post_path(:id)	returns /posts/:id/edit
	post_path(:id)	        returns /posts/:id

   Request routing:
	  If the inbound request is:
		 GET /posts/15 
	  Rails asks the router to match it to the controller action. If the matching route is: 
		get  '/posts/:id, to: 'posts#show' 
	  the request is sent to the posts_controller's 'show' action with { id: '15'} in params.

2. What is REST and how does it relate to the resources routes?

	REST stands for REpresentational State Transfer.  REST is an architectural style. 
	It's principles use current "Web" fundamentals:
	HTTP protocol, Standard unified methods(GET, POST, PATCH, PUT, DELETE), statelessness, 
	URI's which help locate any resource from the web.  REST takes these 4 things and applies 
	certain principles on them. Since REST is an architectural style (a concept) how it is 
	implemented is upto the developer.

	When using HTTP protocol to create REST services,

	1) Everything is a resource.
	
		www.postit.com/image/logo.gif         (Image resource)
		www.postit.com/posts/1200              (Dynamically pulled resource)
		www.postit.com/posts/v001              (Video resource)
		www.postit.com/home.html               (Static resource)

	2) Every resource is identified by an unique identifier. Instead of using a generic URI 
	   the URI will point to a unique identifier.
	
		/categories/3
		/categories/2
		/posts/1
		/posts/2

	3) The interfaces should be simple and uniform. This is achieved by combining 
	   HTTP methods with the URI's instead of using normal method names.
		
		Normal Method Names	  HTTP Verb		  Path(URL)				
		DisplayAllPosts		  GET			  /posts					
		NewPost			  GET			  /posts/new				
		AddPost			  POST			  /posts					
		ShowPost		  GET			  /posts/:id				
		EditPost		  GET			  /posts/:id/edit				
		UpdatePost		  PATCH		      	  /posts/:id				
		RemovePost	 	  DELETE		  /posts/:id	

	4) All response/quests between the server and the client are representations. 
	   The representations are not the resource but a representation of it and there can 
	   also be different representations for a resource (depending on the request, different 
	   forms of data belonging to the resource will be returned in response). A representation 
	   are used to manipulate resources. A representation of a resource has enough information 
	   for a client to modify or delete a resource in the database given the user is authorized. 
	   Representations can be XML, JSON, HTML, csv. Representations are passed on through the 
	   HTTP response body.

	5) All requests are stateless. Each request from any client has all the information necessary 
	   to service the request. Is there is a session state it is held on the client side. It can be 
	   transferred by the server to another service such as a database to maintain a persistent state 
	   for a period of time and allow authentication (for example when a user logs in).

  6) It is a client server architecture. The user may not always have access to the resources 
     (database). The uniform interface connects the user to the server.		

	7) The server responses are cacheable.

	8) It is a layered system. There could be multiple layers of software in between the user 
	   and the server (ie. the user doesn't know who it is talking to for example when a request 
	   is made, the user doesn't know if the response is a cached response or one directly 
	   from the server.

	9) Code on demand. The server can send the executable logic to the user 
	   (eg. executable JavaScript). This is the only optional constraint.

	In Rails, resource routes declares all of the common routes (URI's) that relate to a 
	resourceful controller in a single line. Which then along with HTTP protocol can be used 
	in a RESTful way as described above.

3.  What's the major difference between model backed and non-model backed form helpers?

	  Non-model backed form helpers:
	
	  Forms are primarily used to edit and create a model object. Rails offers several helpers 
	  for generating form elements, ie. text fields, checkboxes, radio button, etc. They all have a 
	  suffix of _tag (e.g.. text_field_tag) and generate a single <input> element. These helpers take 
	  input parameters and the first parameter is always the name of the input element. The controller 
	  then uses this name as the key in the params hash to get the value entered by the user. With radio 
	  button and checkboxes for example there is a second input parameter which is the value of the 
	  input, which is the value that is submitted by the browser if the user ticks the checkbox
	  (the value that will be placed in the params hash). The drawback with this method is that the 
	  the parameter name and the default input value have to be set correctly. Any errors can be avoided 
	  using model object helpers provided by Rails. These helpers don't have the _tag suffix.
	  They also take two arguments: 
	  1) First parameter is the name of an instance variable. 
	  2) The second parameter the name of a method(which is usually an attribute) to call 
	     on the object.  The value that is returned by the method for the object will then be set 
	     by Rails to the input hash by the controller with an appropriate input name. 

	  Example: If @person is defined in the controller and the name "Stitch" is input by the user, 
	  then the form with

  	<%= text_field(:person, :name) %>  
  	
  	will produce <input id="person_name" name="person[name]" type="text" value="Stitch", which, if 
  	submitted will be stored in the the params hash under params[:person][:name]. 
  	The params[:person] can be now be passed to Person.new or if @person is an instance of 
  	Person then it can be used as @person.update_attributes. The second parameter is usually the 
  	name of an attribute of the model. However, this doesn'thave to be so. Model object helpers 
  	will work as long as the object has a name(person_name, person_age, person_title,…….) and 
  	name = method(name = "person[name]", name ="person[age]", name = "person[title]", etc .).

	Model-backed form helpers:
	
	The drawback with model object helpers is that if there are multiple attributes to be edited, 
	then the name of the object will have to be repeated many times. A better method would be 
	to tie the form to the model. This what is achieved by model-backed form helpers. With 
	form_for helper instead of a URL we pass in an object.  
	
	If we have the controller:
	
	def new
	  @person=User.new
	end
	
	The view using form_for looks like:

	<%= form_for :user, @person, :url => {:action = > "create"}, 
	                                :html => {:class => "nifty_form"} do |f| %>
		<%= f.text_field :name %>
		<%= submit_tag "Create" %>
	<% end %>

	where:
	:user is the name of the model.
	@person is the object being edited.
	There is single hash of options containing :url hash and :html hash.
		:url hash is used to pass in routing options
		:html hash is used to pass in HTML options
	The form_for method yields a form builder object (the f variable) which gives 
	additional methods ie. model-backed methods.
	The methods to create form controls are called on the form builder object f

	The HTML output is:
	< form action="/users/create" method="post" class="nifty_form">
		<input id="user_name" name="user[name] size = "15" type="text />
		<input name="commit" type="submit" value="Create" />
	</form>

	When the form is submitted in params the input data is created in a nested structure where 
	the top-level key is post underneath it the input data is within another hash.

4.  How does form_for know how to build the <form> element?

	  It takes an object and from that object it determines where to submit to 
	  (as described in answer to question 3). 

5. What's the general pattern we use in the actions that handle submission of 
   model-backed forms(ie. the 'create' and 'update' actions)?
   
	 When a form is submitted by a user (usually HTML) POST (for create) or 
	 PATCH/PUT (for update) parameters are submitted. For example if the controller 
	 is posts, the URL will be either '/posts' (for create) or '/posts/:id' (for update) 
	 and the data is sent as part of the request body.
	
	Then to create a new record in the database within the create method
		1) A new instance variable is created which will hold the Post object built using the 
		   data submitted by the user
		   
			 @post = Post.new(params[:post])  (This data was passed from the new 
			                                   method to create through the params hash).
			                                   
		2) Then if the new post is saved correctly to the database, the user is 
		   redirected to a named path. If the save was not successful the user is sent 
		   back to the 'new' method to create using the params object.
		   
			 if @post.save
				 redirect_to posts_path
			 else
				 render 'new'
			 end

	To update an existing record in the database, from within the update method a new 
	instance variable is created for a specific Post object which is already within 
	the database using its :id;
	
			@post = Post.find(params[:id])
			
	A conditional statement is used similar to the create method. Instead of save which 
	creates a new record in the database @post.update is used to overwrite attributes of 
	an existing record. If the save is unsuccessful the user is  sent back to the 'edit' 
	method to update using the params object.
	
			if @post.update(params)
				redirect_to post_path
			else
				render 'edit'
			end

6.  How exactly do Rails validations get triggered? 

	  Validations have to be added to the model and an action has to be taken to hit the database.
		ie. in the action
		
		@post = Post.new(params[:post]) won't trigger validations.
		@post.save will trigger validations.

   Where are the errors save?
   
	  ActiveModel::Errors provides a array structure which includes a hash 
	  (@messages = { :title => ["can't be blank"]}) for the object for handling error messages.

   How do we show the validation messages on the interface?
   
	 Using @post.errors.full_messages in the view template the validation messages can 
	 be displayed on the interface.


7.  What are Rails helpers?

	Rails helpers are methods. Rails provides a large number of helpers to work with assets, 
	dates, forms, numbers, model objects etc. By default these helpers are available to all 
	templates. It is also possible to create custom helpers within rails. Custom helpers can 
	be created when a model has complicated logic or reusable functionality. By default each 
	controller includes all helpers. By using the helper class method in ActionController::Base 
	or any controller that inherits from it, additional helpers can be specified. 

8.  What are Rails partials?

	Partials are a convenience method for rendering sub-templates that depends on a single 
	object within the current controller. These sub-templates are called form partials and 
	their names are prefixed with an underscore (_example.html.erb) to distinguish them regular 
	templates that can be rendered on their own.

9.  When do we use partials vs. helpers?

	We use partials when we want to re-use parts of code that depend on a single object in 
	several templates. We use helpers when we want to reuse methods or complicated logic 
	from within controllers and make available to all templates.

10. When do we us non-model backed forms?

	Non-model backed forms are best used when a resource is not created or updated. 
	It is possible to use non-model backed forms when these actions are carried out, 
	however, it involves extra amount of work to generate the forms as described in 
	answer to question 3. Therefore, they are best used for logging in, emailing and 
	when a password is forgotten etc.