Skip to content

Instantly share code, notes, and snippets.

@pixeltrix
Last active January 27, 2025 07:50
Show Gist options
  • Save pixeltrix/8e6773d13e6406963695a7c1bea762a3 to your computer and use it in GitHub Desktop.
Save pixeltrix/8e6773d13e6406963695a7c1bea762a3 to your computer and use it in GitHub Desktop.
Deepseek responses when asked to build a Ruby on Rails controller

Generate a Ruby on Rails controller for a 'Page' resource that is namespaced inside a module called 'Admin'. Implement the index, edit and update actions using path parameter called 'slug' to find the correct model. For the index action sort the pages by the slug column.

Certainly! Below is an example of a Ruby on Rails controller for a Page resource that is namespaced inside a module called Admin. The controller includes the index, edit, and update actions, and it uses a path parameter called slug to find the correct model. The index action sorts the pages by the slug column.

# app/controllers/admin/pages_controller.rb
module Admin
  class PagesController < ApplicationController
    before_action :set_page, only: [:edit, :update]

    # GET /admin/pages
    def index
      @pages = Page.order(:slug)
    end

    # GET /admin/pages/:slug/edit
    def edit
    end

    # PATCH/PUT /admin/pages/:slug
    def update
      if @page.update(page_params)
        redirect_to admin_pages_path, notice: 'Page was successfully updated.'
      else
        render :edit
      end
    end

    private

    # Use callbacks to share common setup or constraints between actions.
    def set_page
      @page = Page.find_by(slug: params[:slug])
      redirect_to admin_pages_path, alert: 'Page not found.' unless @page
    end

    # Only allow a trusted parameter "white list" through.
    def page_params
      params.require(:page).permit(:title, :content, :slug)
    end
  end
end

Explanation:

  1. Namespace and Controller Definition:

    • The controller is defined within the Admin module, so it will be accessible under the /admin namespace.
  2. Index Action:

    • The index action retrieves all Page records and orders them by the slug column.
  3. Edit Action:

    • The edit action finds the Page record by its slug and prepares it for editing.
  4. Update Action:

    • The update action updates the Page record with the provided parameters. If the update is successful, it redirects to the index action with a success notice. If the update fails, it re-renders the edit view.
  5. Private Methods:

    • set_page: This method is used as a before_action callback to find the Page record by its slug. If the record is not found, it redirects to the index action with an alert.
    • page_params: This method uses strong parameters to allow only the title, content, and slug attributes to be updated.

Routes:

To make this controller work, you need to define the routes in your config/routes.rb file:

# config/routes.rb
Rails.application.routes.draw do
  namespace :admin do
    resources :pages, param: :slug, only: [:index, :edit, :update]
  end
end

This will generate the following routes:

  • GET /admin/pages => admin/pages#index
  • GET /admin/pages/:slug/edit => admin/pages#edit
  • PATCH/PUT /admin/pages/:slug => admin/pages#update

Views:

You will also need to create the corresponding views for the index and edit actions in the app/views/admin/pages/ directory.

For example:

  • app/views/admin/pages/index.html.erb
  • app/views/admin/pages/edit.html.erb

This setup should give you a fully functional Admin::PagesController with the specified actions.

Modify the controller so that it raises a 404 instead of redirecting to the index action if the page doesn't exist

To modify the controller so that it raises a 404 (Not Found) error instead of redirecting to the index action when a Page doesn't exist, you can use Rails' rescue_from mechanism or explicitly raise an ActiveRecord::RecordNotFound exception. Here's the updated controller:

# app/controllers/admin/pages_controller.rb
module Admin
  class PagesController < ApplicationController
    before_action :set_page, only: [:edit, :update]

    # GET /admin/pages
    def index
      @pages = Page.order(:slug)
    end

    # GET /admin/pages/:slug/edit
    def edit
    end

    # PATCH/PUT /admin/pages/:slug
    def update
      if @page.update(page_params)
        redirect_to admin_pages_path, notice: 'Page was successfully updated.'
      else
        render :edit
      end
    end

    private

    # Use callbacks to share common setup or constraints between actions.
    def set_page
      @page = Page.find_by!(slug: params[:slug])
    rescue ActiveRecord::RecordNotFound
      raise ActionController::RoutingError, 'Not Found'
    end

    # Only allow a trusted parameter "white list" through.
    def page_params
      params.require(:page).permit(:title, :content, :slug)
    end
  end
end

Key Changes:

  1. find_by! Instead of find_by:

    • The find_by! method raises an ActiveRecord::RecordNotFound exception if no record is found. This is more appropriate for raising a 404 error.
  2. Rescue and Raise a 404:

    • If find_by! raises an ActiveRecord::RecordNotFound exception, it is rescued, and an ActionController::RoutingError with the message 'Not Found' is raised. This results in a 404 error being returned to the client.

How It Works:

  • When a request is made to a route like /admin/pages/nonexistent-slug/edit, the set_page callback will attempt to find the Page with the given slug.
  • If no such Page exists, find_by! raises an ActiveRecord::RecordNotFound exception.
  • The rescue block catches this exception and raises an ActionController::RoutingError, which Rails interprets as a 404 error.

Routes:

No changes are needed in the routes file. The existing routes will work as expected.

# config/routes.rb
Rails.application.routes.draw do
  namespace :admin do
    resources :pages, param: :slug, only: [:index, :edit, :update]
  end
end

Testing the 404:

To test this behavior, you can:

  1. Start your Rails server.
  2. Visit a URL like /admin/pages/nonexistent-slug/edit in your browser or use a tool like curl or Postman.
  3. You should see a 404 error page (or a JSON response with a 404 status if your app is API-only).

This approach ensures that invalid requests are handled appropriately and consistently with HTTP standards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment