guide.rubyonrails.org Part2 Flashcards
Apparently when you generate a model you create a database migration file inside the db/migrate directory. What are migrations?
Migrations are Ruby classes that are designed to make it simple to create and modify database tables.
Ruby uses rake commands to run migrations (wtf is rake? – think of rake as a task builder/maker for admins). It’s possible to undo a migration, after it’s been applied to your database. Migration filenames include a timestamp to ensure that they’re processed in the order that they are created.
Explain the different duties of your apps MVC.
The Model does the grunt work. The view has the happy face. The controller is the mastermind.
https://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
What occurs inside your rails application when a user enters a URL into the brrowser and clicks return.
So the url entry is considered a request. The request is received by a browser (such as http://mysite.com/video/show/15) and the browser talks to the server. The WEBrick server receives the request, uses routes to determine which controller to use. The default pattern is controller/action/id.
The WEBrick server finds the controller to use, creates a new controller calls the action and passes the parameters.
Controllers do the mastermind work of parsing/making sense of user requests, data submissions, cookies, sessions and the browser stuff. The ‘video’ in our URL is our controller, the ‘show’ is the action within the controller and the controller asks our model to look up video ‘15.’ The controller sends out orders and the controller is the component that eventually serves the content to the browser! For as much as the controller does though, the controller doesn’t really care about the details, it leaves that up to the model to handle. The controller basically bosses the view and the model around.
Models are Ruby classes, in this case they retrieve video 15 from the database. Models talk to the database, store and validate data, perform the business logic and otherwise do the heavy lifting. The model reports back to the controller with what it has.
The view is what the user sees: HTML, CSS, XML, JS, JSON. They merely read what the controller gives them, in this case the controller gives the view video 15 and the view displays this in the form of HTML.
Eventually the controller returns the response body and metadata (caching, headers, redirects) to the WEBrick server. The WEBrick server combiens the raw data into a proper HTTP response and sends it to the browser. Viola!
Users never interact with the controller directly, only through the WEBrick server.
We know how to create views and controllers, how do we create models?
Models are created in the same way as controllers and views are created with Rails GENERATORS.
$ rails generate model Article title:string text:text
Above we call our rails generate script then we name the type of MVC item we’d like to create, we give it a name, then we give it a title and text type.
NOTE: Because models are the workhorse of our MVC system and they deal with the batabase communication and retrievals creating a model also creates a database within our rails app. Along with the database we also have something called a migration class!!!
So what are migration classes?
Migration classes are ruby classes are designed to make designing and modifying database tables EASY.
When you think migration think moving around data in databases, or designing/modifying database tables.
Migration classes are created automatically for you when you create your model, and they help you do the db work of models.
How do you call the migration table so you can view it?
$ bin/rake db:migrate
What are strong parameters, and why am I getting stuck on them?
Strong parameters are Rails’ way of forcing you to write secure apps, it’s a security measure. Rails wants us to tell it exactly which parameters are allowed into our controller actions, and remember actions are like functions. (Rails basically needs us to ensure the arguments being passed into our functions wouldn’t cause any trouble, hence parameters must be strong).
We whitelist our controller parameters.
How does one create an article?
How does one create an article model?
How does one run a migration?
How do you save data in a controller?
How does one show the articles?
(Sections 5.1 - 5.7)
Remember our REST resource is called articles, and our article is just a collection of things. Our article has all the components of an MVC. We generate our controller, created a new action inside it, and we created a view shortly after, with the embedded ruby code of a form using the form_for method.
Once our form is created we need to implement a ‘create’ action so that our forms submit button both routes us to a new page and uploads the appropriate db content unto the page. This action is devised inside the controller. At this point the create action works and stores the db cotent, we can even choose to render it, but it does not display it on a browser page as we’d like.
The last piece of the MVC, the model, is generated and the task it has is to better access our database with the use of in-built migration tools. Models are classes so they have capital first letters and are singular. We can view the migration file to see how it runs.
Right, so we have our Article resources MVC, but we are still yet to use our model. In section 5.6 we must change the create action inside our controller so as to have it save our database content inside the newly created Article model class, we must also attend to rails security measure- strong parameters.
Once our controller’s create action saves our database content in the model the last thing to do is show it! We create a show action in our controller and also create a show view that displays our content in the right way.
Viola you have the makings of a working app, albeit incomplete.
Walkthrough the steps of listing our articles.
(5.8)
Much like our showing of our articles content we need two things if we want to create a list of our articles: we need a new controller action and a view. So we create a index action in our controller and a view called index.html.erb.
Question: how is it that our url is set to articles and the other views are articles/new?
