Lecture 4. Ruby on Rails 1 / 52

Size: px

Start display at page:

Download "Lecture 4. Ruby on Rails 1 / 52"

Adrian Little
5 years ago
Views:

1 Lecture 4 Ruby on Rails 1 / 52

2 Homeworks 2 & 3 Grades were released for homework 2 Homework 3 was due last night Everyone got a style freebie since my default setup ignores spec files and I didn't change it 2 / 52

3 Go Birds! In honor of the Philadelphia Eagles winning their first Super Bowl, I will be giving everyone another free late day You can use it on any assignment during the semester This brings your late day total up to 2 (unless you've already used 1) 3 / 52

4 19x Shared Lecture Last week discussed Internet Basics This week will go over HTML & CSS Please go to this lecture if you've never worked with HTML & CSS before If you cannot attend, please go through CodeCademy to learn HTML I can't dedicate much time to HTML/CSS in lecture, but they are vital to being a web developer 4 / 52

5 O ce Hours Weekday Time Location TA Sunday 11am-12pm Harrison Mezz Sanjana 2-3pm Harnwell Mezz Desmond Monday 5:30-6:30pm Moore 100 Sanjana 6:30-7:30pm Moore 100 Zhilei Tuesday 4-5pm Moore 100 Zhilei 5-6pm Moore 100 Desmond 6-7pm Moore 100 Jackie Wednesday 7-8pm Harnwell Mezz Jackie 5 / 52

6 HTTP 6 / 52

7 HTTP Stands for HyperText Transfer Protocol A client (e.g. web browser, phone, computer, etc.) sends a request to a server The server receives this request and sends back a response This response is usually a web page (i.e. HTML with accompanying files) or data, usually in XML or JSON 7 / 52

8 Client-server 8 / 52

9 HTTP Verbs The five most common types of HTTP requests are: GET POST PUT/PATCH DELETE 9 / 52

10 GET Request This is usually the default type of request sent When you enter a URL or click a link, a GET request is sent for the webpage When a webpage updates, it probably sent a GET request behind the scenes to get the new data As the name suggests, it should only be used to get something 10 / 52

11 POST Request This should be used to send data from the client to the server While you can technically use GET requests to send data, you should always use a POST request instead It's much more robust and secure This is the default type of request sent when submitting a form (i.e. signing into a website) 11 / 52

12 PUT/PATCH Request This should be used to update something on the server You could technically use a POST request to update as well, but it is convention to use a PUT or PATCH request instead The main difference between PUT and PATCH: A PUT request is used to update an entire record A PATCH request is used to update part of it 12 / 52

13 DELETE Request This should be used to delete something on the server While you could technically use a POST request to delete, it is convention to use a DELETE request instead 13 / 52

14 MVC 14 / 52

15 MVC Stands for Model-View-Controller Every community has different definitions and conventions for MVC Rails is no different Ignore the conventions of other communities when working with Rails 15 / 52

16 Controller The controller is the layer of the application that handles HTTP requests It communicates with both the Model and the View The controller should try to pass off as much logic as possible to the Model 16 / 52

17 Model The model is the layer of the application with the crux of the application's logic It should be the main place where the database is directly accessed In general, the controller will make a request to the model and the model will send back the requested data 17 / 52

18 View The view is the layer of the application that the user will see and interact with It should have very minimal logic inside of it In general, the controller will send data (likely retrieved from the model) to the view to be rendered to the user 18 / 52

19 19 / 52

20 Ruby on Rails 20 / 52

21 Ruby on Rails History Created by David Heinemeier Hansson (DHH) First open sourced in July 2004 Revolutionized web development from 2005 to / 52

22 Ruby on Rails Also referred to as Rails It is an opinionated web framework that allows you to quickly get a website up and running HUGE proponent of Convention over Configuration and Don't Repeat Yourself principles We will be using version It is extremely important that you use the correct version Make sure that you are NOT using / 52

23 Getting Started gem install rails -v Create a Rails app: rails new app_name Creates a directory of your rails app with all the basic directories and files By default, it will bundle install all of the gems in the Gemfile 23 / 52

24 Directory Structure **app/ bin/ Organizes application components Models, views & controllers go here Images, stylesheets, JavaScripts specific to this application go in app/assets/ The majority of the changes you'll make will be in this directory Contains app executables 24 / 52

25 Directory Structure **config/ **db/ Contains all of the application's configuration files Home to the routes file that declares the app's routes Other than editing config/routes.rb, you won't spend much time in here Contains all database related files (db/schema.rb, migration files, db/seeds.rb, etc.) 25 / 52

26 Directory Structure lib/ log/ Houses code that could be reused by different applications Great place for modules like Referenceable! Contains all of the application logs public/ HTML templates for errors, favicon, etc. 26 / 52

27 Directory Structure test/ tmp/ Rails uses MiniTest Your homework assignments will have a spec/ folder instead Temporary files vendor/ Contains third party libraries 27 / 52

28 Starting the Server/Console rails server (or rails s) will start the Rails app Visit in a web browser You've got a Rails site! rails console (or rails c) will start a Rails console This allows you to interact with individual pieces of your Rails app Similar to the consoles that you were provided in the first assignments 28 / 52

29 Creating a Homepage What we'll need: A controller to handle the request when the user visits the homepage (root) A view to be able to show actual content to the user A route to tell Rails what controller to use when a user visits the root of our app We're not working with data so we won't need a model 29 / 52

30 Controllers Your controllers should be placed inside of app/controllers/ General naming convention: app/controllers/{controller_name}_controller.rb Should inherit from ApplicationController You define methods in the controller that are known as actions Controller actions are mapped to specific routes Specify what should happen when a request for a specific route is made 30 / 52

31 Homepage Controller Define a Welcome controller and define an index action inside of it We will set up this controller and action to handle the request to our site's homepage # app/controllers/welcome_controller.rb class WelcomeController < ApplicationController def index end end 31 / 52

32 Routes Your routes should be defined inside of config/routes.rb Routes map a request type and a path to a specific controller and action When you define a route, you specify: The type of request The corresponding path What controller action should be used request_type 'path', to: 'controller#action' Run rails routes to view all of the routes you've defined 32 / 52

33 Homepage Route Our homepage route: Request Type: get Path: / (the root of our application) Controller: welcome Action: index # config/routes.rb Rails.application.routes.draw do # The following are equivalent, use the latter: # get '/', to: 'welcome#index' # root to: 'welcome#index' root 'welcome#index' end 33 / 52

34 Views Your views should be placed inside of app/views/ General naming convention: app/views/{controller_name}/{controller_action}.html.erb Unless you tell it otherwise, a controller action will render the view file with its same name by default The.html.erb ending allows you to write HTML code with Ruby embedded inside of it 34 / 52

35 Application View Located at: app/views/layouts/application.html.erb Defines the basic layout for every view in your app Contains the HTML boilerplate code Contains the yield keyword This is where the HTML that you write in your individual views will be placed This means that you don't have to write out all of the boilerplate for every view 35 / 52

36 Homepage View Start by creating app/views/welcome/index.html.erb We don't need to include the HTML boilerplate  <h1>welcome to our Rails Application!</h1> <p>it's a great app!</p> Visit the root of the application to see our homepage in action! 36 / 52

37 ERB erb stands for Embedded RuBy Our views files end in.html.erb This allows us to include Ruby code directly in our views files This means that we can include dynamic content! 37 / 52

38 ERB Tags In an erb file, any Ruby code placed between: <% %> will be executed, but not printed Used for things like iterators <%= %> will be executed and printed <%# %> will be a comment There are many other variations, but you will use these the most Find out more here 38 / 52

39 Homepage ERB <%# app/views/welcome/index.html.erb %> <p>please thank our developers:</p> <ul> <% ['Jackie', 'Desmond', 'Sanjana'].each do name %> <li><%= name %></li> <% end %> </ul> will generate the following HTML code: <p>please thank our developers:</p> <ul> <li>jackie</li> <li>desmond</li> <li>sanjana</li> </ul> 39 / 52

40 Communicating between Controller & View You can pass data from the controller to the view Very important for following MVC best practices If you define an instance variable in a controller action, it will be available in its corresponding view 40 / 52

41 Passing Data to our Homepage View # app/controllers/welcome_controller.rb class WelcomeController < ApplicationController def = ['Jackie', 'Desmond', 'Sanjana', 'Zhilei'] end end <%# app/views/welcome/index.html.erb %> <ul> do name %> <li><%= name %></li> <% end %> </ul> 41 / 52

42 What about other requests? In general, GET requests are the only requests that have a corresponding view file Other request types usually handle the request you sent and then do one of the following: Redirect the browser to another path using a GET request (usually when the request was successful) Render the view of another controller action (usually when the request was not successful) 42 / 52

43 Example: Logging in You make a GET request to which renders the login page You type in your username and password and click submit This triggers a POST request which does one of two things: If the info you entered was correct, it redirects you to using a GET request If the info you entered was incorrect, it rerenders the login page (probably with an error message) 43 / 52

44 POST Request Example We will make a POST request that handles a user subscribing to a newsletter They will submit a form with their full name and What we'll need: A form - we'll add it to the homepage A new controller action - we'll add it to the welcome controller A route Note that we are not creating a new view 44 / 52

45 Subscribe Route Our subscribe route will be a POST request to '/subscribe' We will make a controller action called subscribe inside of the welcome controller # config/routes.rb post '/subscribe', to: 'welcome#subscribe' 45 / 52

46 Form Instead of creating a form directly in HTML, we use Rails helpers to generate one using Ruby Rails 5.1 introduced the form_with tag which we will use for generating all forms <%# app/views/welcome/index.html.erb %> <%= form_with url: '/subscribe' do form %> <%= form.text_field :name, placeholder: 'Name' %> <%= form. _field : , placeholder: ' ' %> <%= form.submit 'Subscribe' %> <% end %> 46 / 52

47 Controller Action Check to make sure that the user entered in a name and Redirect to a success page if successful Re-render the subscribe form otherwise # app/controllers/welcome_controller.rb def subscribe if params[:name].present? && params[: ] # TODO: Save subscription in database redirect_to '/' else render :index end end 47 / 52

48 Params You'll notice that we referenced params in the previous slide The params hash will contain information from the user's request & can always be accessed You can get the names of the controller and action with params[:controller] and params[:action] You can get submitted form values You can also get parameters from the URL itself (such as an id) 48 / 52

49 More on Routes Routes can have parameters get '/subscribed/:user_name', to: 'welcome#subscribed' In the above route, user_name will be a parameter & is a wildcard matcher /subscribed/jackie-askins, /subscribed/15, /subscribed/aoisjfisajosjs will all match this route We can access the user_name from params like this: params[:user_name] View all routes defined in an application by running rails routes in the command line 49 / 52

50 Resources Ruby on Rails Guides I am a HUGE fan of the Ruby on Rails Guides They're very beginner-friendly and explain concepts clearly You can find the answer to almost any question here Ruby on Rails API This is a little more confusing, but great for finding more specific details 50 / 52

51 Homework 4 51 / 52

52 Homework 4 In this assignment, you will be building a RESTful application from scratch We will discuss REST in detail next week You will be provided with the model and view layers, and will focus solely on the controller in this assignment This is the first assignment where you will lose points for best practices 52 / 52

Lecture 4. Ruby on Rails 1 / 49

Lecture 4. Ruby on Rails 1 / 49 Lecture 4 Ruby on Rails 1 / 49 Client-Server Model 2 / 49 What is it? A client (e.g. web browser, phone, computer, etc.) sends a request to a server Request is an HTTP request Stands for HyperText Transfer