1722970265

Learn Ruby on Rails lesson 3


# Learn Ruby on Rails lesson 3<hr> In the last lesson we should have generated some files. The main one that we wana focus on at the moment is the posts controller. Refer back to the last lesson to remember what the controllers role is within the rails ecosystem. When you run a generator it should give you a path to the files that it made. You should be able to find the post_controller in the app/ dir under controllers. Take a look. For now the only think that should be within that file is: ``` class postController < ApplicationController def index end end ``` What is going on here is the post controllers will inherit everything from the application_controller. That application controller has alot of methods within it that we will need to use to interact with the back-end. By default this will be on every controller you generate as its a core part of its functionality. Keep in mind that it can be changed. If you have a very specific use case for a controller you can choose to not make it inherit any of the application_controllers methods and build everything from scratch. Most of the times this isnt needed but rails lets you do whatever you want. In another case you may want a new controller to inherit from a controller that you have already made. Think about it as nested controllers. special_purpose controller < custom controller < application controller. You can nest them like this so you wont have to re-write all the custom controllers methods into the special controller, but you will still have access to the general application controller methods. Save you self some time and use this when making your own projects later. Back on task now. Right now the post_controller does not have any of its own methods in it. That means by default it will return whatever exist within the view that shares its same name. When we ran that generator to make the post controller it also made a view sharing the same name as the predefined method. Take a look at it under views within the main app/ dir. Open up the index.html.erb and remove any content within. Replace it with `<p>hello world</p>` or something else of your choosing. If you would like you can head back to the post controller and add a new method. Add ``` def test_thing end ``` under the index method. Now head back to the view/post and touch test_thing.html.erb. Place whatever you want in here. Now to see the changes that we have made we are going to need to start up the rails server again. head over to localhost:3000/posts. By default your index page will be what shows up, you can navigate to your test_thing by appending #test_thing to the url. Feel free to change the name of this to whatever you want. Congrats now your custom content is live. One issue that we need to address is that when starting the server up and navigating to localhost it dont take us to your index page which is what we indent to be the home page. We can fix this by heading over to routes.rb and making sure these lines are included: ``` root "post#index" get "/post", to: "post#index" ``` This makes the home page our post page and will return the view specifically from the index which is what we want returned. <hr> Now its time to make this page something better then just a plain html response. At this time remove your test_thing html.erb aswell as it from the post_controller page as I dont want it to return any more. We are going to use another generator to make a model this time. With you server stopped we want to run: `rails generate model Post title:string body:text` Take notice how we say post and most posts. That is because in the DB we will want multiple post on the posts page. it needs to be singular not plural for this to work. Each of these post within posts will have 2 input fields, a title and a large input for large text. You should now have a model under app/model called post. We now need to update the db the reflect this change. `rails db:migrate` the change that it will make will follow this format: ``` class CreatePost < ActiveRecord::Migration[7.0] def change create_table :Posts do |t| t.string :title t.text :body t.timestamps end end end ``` So within Posts, we make multiple Post which each have a title and text content. Timestamps are automatically added but we dont really make use of those. Mostly just for logging purposes. What can we do with this new table we just made. Lets take a look. Run `rails console` . This will open a new irb session so we can play around. Lets add something to our DB. ``` post = post.new(title: "Hello world", body: "this is my first post") ``` now just type post into your irb session. It should return all of the entries that fall under the post within the posts column in the table. When we do anything in irb is is all in its own little environment and wont change the real DB however. irb is for testing in most cases and you dont want to break something accidentally. To make out changes live we need to tell the db that everything that happened within this irb session we want to make true. `post.save` does this for us. It should return true if it changed the table for you. If you would like to make more post just repeat the steps above, make sure to save. Now each post that is made will have its own id (and time stamp) which is a convenient way for us to specify which post we want to see. We can return all post by running Post.all or a specific one by Post.find(id) such as Post.find(3). Congrats. Next lesson we will modify our home page to show the posts that you have created. If you have any questions you can find me in the ruby room.

(1) Comments
amargo85
amargo85
1723052759

I think it was worth the wait. The ruby people have to come here and contribute


Welcome to Chat-to.dev, a space for both novice and experienced programmers to chat about programming and share code in their posts.

About | Privacy | Terms | Donate
[2024 © Chat-to.dev]