Rails Helpers
Reviewed 7 Crud Actions:
- Read: get /tasks (rails controller/action tasks#index)
- Read: get /tasks/:id (rails controller/action tasks#show)
- Create: get /tasks/new (rails controller/action tasks#new)
- Create: post /tasks (rails controller/action tasks#create)
- Update: get /tasks/:id/edit (rails controller/action tasks#edit)
- Update: put /tasks/:id (rails controller/action tasks#update)
- Destroy : delete /tasks/:id (rails controller/action tasks#destroy)
If you run rake routes on command line, you get that information. Additionaly, first column is prefix. (BTW, this is not the order that rake routes produces)
- tasks
- task
- new_task
-
- edit_task
-
-
The prefixes are used in helper methods like link_to, etc.
You can append _path or _url to them. LIke tasks_path or tasks_url. _path is a relative path, _url is an absolute path
This is kinda like a shortcut, but it's not really shorter. But it is way more explicit, readable.
Some don't get a prefix (note ____ above), but you can kinda still use them. Post to /tasks would be able to use tasks. All the others without one would be able to use task prefix.
When using helpers on any of the ones that deal with an individual existing task (i.e. task, edit_task), you need to pass in the id of the particiular task. Something like link_to "link text" task(1) NOTE that this is hardcoded. In reality it will mostly be passed in a variable like link_to "link text" task(task)
As shown above, you can pass in a reference to the entire object - i.e. task. You do not need to say task.id. It just knows.
Seeding a Database
from command line, run db:seed this will run the seed.rb file in your database folder the seed file creates data that you want/need for your app - like instances of tasks, etc.
in general, you would do the following to get your data set up; rake db:create, rake db:migrate, rake db:seed
FORMS
rails gives us an alternative to writing forms in HTML a form is a tool to get structured data from a user
request/response cycle in forms:
User submits a form and it is a post request to the server. You don't want the server to return content because that can cause screwy things if the page is refreshed (like form resubmission, etc). To solve that issue: POST - redirect - GET loop Instead of returning content, the server sends back a redirect that triggers a new get resquest
REVIEWED 7 CORE REST ACTIONS (again) index new/create edit/update destroy
Which of the above involve forms??? NEW and EDIT
First off, these are often the same form so will use a partial. Something like new.html.erb file would have: <%= render :partial => "form" >
Then the partial is going to use the form helpers, mostly form_for
In essence form_for is making the form opening and closing tags for html - but also figures out a lot of stuff, including whehter it's an edit or new.
That is, it's figuring out what action to submit the form to (i.e. /tasks or tasks/:id) what method call (i.e. POST or PUT)
Under the hood, form_for calls some methods to figure this out - mostly .new_record?
The result of those method calls determine the action and method
Reccomended: read the form_for API documentation. linked in lesson plan.
text and text_area form helpers are most straightforward. The rest are surprisingly complex to use for exp, radio buttons and checkboxes need to get wrapped together so rails know what ones are grouped together
Alternatives to form_for(links on lesson plan). There are a few form builder plug ins
- Formtastic
- SimpleForm
In essence they will look at your data structure for that model and figure out what type of form input is needed.
Really good, but also impt to understand the built in tool.