Why controllers handle requests in Ruby on Rails - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to define a controller action that responds to a request.

Ruby on Rails

class ArticlesController < ApplicationController
  def index
    @articles = Article.all
    render [1]
  end
end

Drag options to blanks, or click blank then click option'

A:edit

B:show

C:new

D:index

Attempts:

3 left

💡 Hint

Common Mistakes

Using :show or :new instead of :index causes the wrong view to render.

Forgetting to render a view leaves the response empty.

The index action typically renders the :index view to show all articles.

2fill in blank

medium

Complete the code to fetch a specific article by its ID in the controller.

Ruby on Rails

class ArticlesController < ApplicationController
  def show
    @article = Article.[1](params[:id])
  end
end

Drag options to blanks, or click blank then click option'

Awhere

Ball

Cfind

Dfind_by

Attempts:

3 left

💡 Hint

Common Mistakes

Using where returns a collection, not a single record.

Using all returns all records, not one.

The find method fetches a record by its primary key, which is usually the ID.

3fill in blank

hard

Fix the error in the controller action to correctly redirect after creating an article.

Ruby on Rails

def create
  @article = Article.new(article_params)
  if @article.save
    redirect_to [1]
  else
    render :new
  end
end

Drag options to blanks, or click blank then click option'

Aarticle_path(@article)

Bnew_article_path

Carticles_path

Dedit_article_path(@article)

Attempts:

3 left

💡 Hint

Common Mistakes

Redirecting to articles_path goes to the index, not the new article.

Redirecting to new_article_path goes back to the form.

After creating an article, redirecting to its show page uses article_path(@article).

4fill in blank

hard

Fill both blanks to complete the controller action that updates an article and redirects properly.

Ruby on Rails

def update
  @article = Article.find(params[:id])
  if @article.[1](article_params)
    redirect_to [2]
  else
    render :edit
  end
end

Drag options to blanks, or click blank then click option'

Aupdate

Bupdate_attributes

Carticle_path(@article)

Darticles_path

Attempts:

3 left

💡 Hint

Common Mistakes

Using update_attributes is deprecated in newer Rails versions.

Redirecting to articles_path goes to the index, not the updated article.

The update method updates the record, and redirecting to article_path(@article) shows the updated article.

5fill in blank

hard

Fill all three blanks to complete a controller action that deletes an article and redirects to the articles list.

Ruby on Rails

def destroy
  @article = Article.find(params[:id])
  @article.[1]
  redirect_to [2], notice: [3]
end

Drag options to blanks, or click blank then click option'

Adestroy

Barticles_path

C'Article was successfully deleted.'

Ddelete

Attempts:

3 left

💡 Hint

Common Mistakes

Using delete does not run callbacks, destroy is preferred.

Forgetting to redirect leaves the user on the deleted article page.

The destroy method deletes the record, then redirecting to articles_path shows the list with a notice message.

Practice

1. Why do Rails controllers handle user requests?

easy

A. To decide how the app should respond to user actions

B. To store data permanently in the database

C. To style the web pages with CSS

D. To manage server hardware resources

Solution

1. Step 1: Understand the role of controllers in Rails

   Controllers receive user requests and decide what the app should do next, such as showing a page or saving data.

2. Step 2: Differentiate controller responsibilities from other parts

   Storing data is handled by models, styling by CSS, and hardware management is outside Rails scope.

3. Final Answer:

   To decide how the app should respond to user actions -> Option A

4. Quick Check:

   Controllers handle requests = A [OK]

Hint: Controllers decide app response to user actions [OK]

Common Mistakes:

• Confusing controllers with models for data storage
• Thinking controllers handle styling or hardware
• Believing controllers directly manage databases

2. Which of the following is the correct way to define an action named show in a Rails controller?

easy

A. function show() {
// action code
}

B. def show
# action code
end

C. show => {
// action code
}

D. action show {
// action code
}

Solution

1. Step 1: Recall Ruby method syntax in Rails controllers

   Rails controller actions are Ruby methods defined with def action_name and end.

2. Step 2: Identify correct syntax among options

   def show # action code end uses Ruby method syntax; others use JavaScript or invalid syntax.

3. Final Answer:

   def show\n # action code\nend -> Option B

4. Quick Check:

   Ruby method syntax = A [OK]

Hint: Rails actions are Ruby methods using def/end [OK]

Common Mistakes:

• Using JavaScript function syntax in Rails controllers
• Trying to define actions with arrow functions
• Using invalid keywords like 'action'

3. Given this controller code, what will be the rendered output when visiting /welcome/greet?

class WelcomeController < ApplicationController
  def greet
    @message = "Hello, Rails!"
  end
end

Assuming the view greet.html.erb contains:

<h1><%= @message %></h1>

medium

A. Hello, Rails!

B. <%= @message %>

C. Hello, Rails!

D. Error: undefined variable

Solution

1. Step 1: Understand controller sets instance variable

   The controller action greet sets @message to "Hello, Rails!" which is accessible in the view.

2. Step 2: View renders the instance variable inside <h1> tags

   The view uses ERB syntax <%= @message %> to insert the message text inside an <h1> element.

3. Final Answer:

   <h1>Hello, Rails!</h1> -> Option C

4. Quick Check:

   Instance variable rendered in view = B [OK]

Hint: Instance variables in controller appear in views with <%= %> [OK]

Common Mistakes:

• Expecting raw variable name instead of its value
• Confusing plain text with HTML tags
• Assuming variable is undefined without @

4. Identify the error in this controller code snippet:

class ProductsController < ApplicationController
  def index
    @products = Product.all
  end

  def show
    @product = Product.find(params[:id])
  end

  def create
    product = Product.new(params[:product])
    if product.save
      redirect_to product_path(product)
    else
      render :new
    end
  end
end

medium

A. Using params[:product] directly without strong parameters

B. Missing return statement in create action

C. No instance variable @product in create action

D. Incorrect inheritance from ApplicationController

Solution

1. Step 1: Review how parameters are handled in create action

   The code uses params[:product] directly, which is unsafe and disallowed in modern Rails without strong parameters.

2. Step 2: Identify missing strong parameters usage

   Rails requires filtering params with methods like product_params to permit only allowed attributes.

3. Final Answer:

   Using params[:product] directly without strong parameters -> Option A

4. Quick Check:

   Strong parameters required = D [OK]

Hint: Always use strong parameters to permit attributes [OK]

Common Mistakes:

• Ignoring strong parameters and using raw params
• Thinking return statements are needed in Rails actions
• Confusing instance variables with local variables

5. You want a controller action to handle both showing a form and processing form data for creating a new user. Which approach best follows Rails controller patterns?

hard

A. Use one action create to show form and save user

B. Use one action new to both show form and save user

C. Handle form display and data processing in the view file

D. Use separate actions: new to show form, create to process data

Solution

1. Step 1: Understand Rails RESTful controller conventions

   Rails uses separate actions: new to display the form, and create to handle form submission and save data.

2. Step 2: Evaluate options against best practices

   Combining form display and data processing in one action or view breaks separation of concerns and Rails conventions.

3. Final Answer:

   Use separate actions: new to show form, create to process data -> Option D

4. Quick Check:

   Separate new and create actions = C [OK]

Hint: Use new for form, create for saving data [OK]

Common Mistakes:

• Combining form display and processing in one action
• Trying to handle logic inside views
• Ignoring Rails RESTful conventions