Hoe u geneste resources kunt maken voor een Ruby on Rails-toepassing

Introductie

Ruby on Rails is een webapplicatieframework geschreven in Ruby dat ontwikkelaars een opiniegedreven benadering van applicatieontwikkeling biedt. Werken met Rails geeft ontwikkelaars:

• Conventies voor het omgaan met zaken als routering, stateful data, en asset management.
• A firm grounding in the model-view-controller (MCV) architectural pattern, which separates an application’s logic, located in models, from the presentation and routing of application information.

Naarmate je complexiteit toevoegt aan je Rails-applicaties, zul je waarschijnlijk werken met meerdere modellen, die de zakelijke logica van je applicatie vertegenwoordigen en communiceren met je database. Het toevoegen van gerelateerde modellen betekent het vaststellen van betekenisvolle relaties tussen hen, die dan van invloed zijn op hoe informatie wordt doorgegeven via de controllers van je applicatie, en hoe het wordt vastgelegd en teruggegeven aan gebruikers via views.

In deze tutorial bouw je voort op een bestaande Rails-applicatie die gebruikers feiten biedt over haaien. Deze applicatie heeft al een model voor het omgaan met haaiendata, maar je zult een genest resource toevoegen voor berichten over individuele haaien. Dit stelt gebruikers in staat om een breder scala aan gedachten en meningen over individuele haaien op te bouwen.

Vereisten

Om deze tutorial te volgen, heb je nodig:

• A local machine or development server running Ubuntu 18.04. Your development machine should have a non-root user with administrative privileges and a firewall configured with ufw. For instructions on how to set this up, see our Initial Server Setup with Ubuntu 18.04 tutorial.
• Node.js en npm zijn geïnstalleerd op uw lokale machine of ontwikkelingsserver. Deze tutorial maakt gebruik van Node.js versie 10.16.3 en npm versie 6.9.0. Voor begeleiding bij het installeren van Node.js en npm op Ubuntu 18.04, volg de instructies in de sectie “Installeren met een PPA” van Hoe Node.js te installeren op Ubuntu 18.04.
• Ruby, rbenv, en Rails zijn geïnstalleerd op uw lokale machine of ontwikkelingsserver, volgend op Stappen 1-4 in Hoe Ruby on Rails te installeren met rbenv op Ubuntu 18.04. Deze tutorial maakt gebruik van Ruby 2.5.1, rbenv 1.1.2, en Rails 5.2.3.
• SQLite is geïnstalleerd, en een eenvoudige haaieninformatie-applicatie is gemaakt, volgens de instructies in Hoe een Ruby on Rails Applicatie te Bouwen.

Stap 1 — Het Nesten van het Model

Onze applicatie zal gebruik maken van Active Record associaties om een relatie tussen de modellen Shark en Post op te bouwen: posts zullen toebehoren aan specifieke haaien, en elke haai kan meerdere posts hebben. Onze Shark en Post modellen zullen dus gerelateerd zijn via belongs_to en has_many associaties.

De eerste stap om de applicatie op deze manier op te bouwen, zal zijn om een Post model en gerelateerde bronnen aan te maken. Hiervoor kunnen we de rails generate scaffold opdracht gebruiken, die ons een model, een database migratie om het databaseschema aan te passen, een controller, een volledige set views om standaard Create, Read, Update en Delete (CRUD) operaties te beheren, en sjablonen voor partials, helpers, en tests zal geven. We zullen deze bronnen moeten aanpassen, maar het gebruik van de scaffold opdracht zal ons tijd en energie besparen aangezien het een structuur genereert die we als startpunt kunnen gebruiken.

Zorg er eerst voor dat je in de sharkapp directory bent voor het Rails project dat je hebt aangemaakt in de vereisten:

cd sharkapp

Maak je Post bronnen aan met de volgende opdracht:

rails generate scaffold Post body:text shark:references

Met body:text vertellen we Rails om een body-veld op te nemen in de database-tabel posts – de tabel die overeenkomt met het Post-model. We voegen ook het :references-sleutelwoord toe, dat een associatie opzet tussen de Shark– en Post-modellen. Specifiek zorgt dit ervoor dat een externe sleutel die elk haai-item in de sharks-database vertegenwoordigt, wordt toegevoegd aan de posts-database.

Zodra je het commando hebt uitgevoerd, zie je output die bevestigt welke resources Rails heeft gegenereerd voor de applicatie. Voordat je verder gaat, kun je je database-migratiebestand controleren om te kijken naar de relatie die nu bestaat tussen je modellen en database-tabellen. Gebruik het volgende commando om de inhoud van het bestand te bekijken, waarbij je ervoor zorgt dat je de tijdsaanduiding op je eigen migratiebestand vervangt door wat hier wordt getoond:

cat db/migrate/20190805132506_create_posts.rb

Je zult de volgende output zien:

Output
class CreatePosts < ActiveRecord::Migration[5.2]
  def change
    create_table :posts do |t|
      t.text :body
      t.references :shark, foreign_key: true

      t.timestamps
    end
  end
end

Zoals je kunt zien, bevat de tabel een kolom voor een externe sleutel van een haai. Deze sleutel zal de vorm hebben van model_naam_id – in ons geval shark_id.

Rails heeft de relatie tussen de modellen ook elders vastgesteld. Kijk eens naar het nieuw gegenereerde Post-model met het volgende commando:

cat app/models/post.rb

Output
class Post < ApplicationRecord
  belongs_to :shark
end

De belongs_to-associatie stelt een relatie in tussen modellen waarbij een enkele instantie van het declarerende model behoort tot een enkele instantie van het genoemde model. In het geval van onze applicatie betekent dit dat een enkele post behoort tot een enkele haai.

Naast het instellen van deze relatie heeft het rails generate scaffold commando ook routes en weergaven voor berichten aangemaakt, net zoals het deed voor onze haai-resources in Stap 3 van Hoe bouw je een Ruby on Rails applicatie.

Dit is een nuttige start, maar we zullen enkele aanvullende routing moeten configureren en de Active Record associatie voor het Shark model moeten versterken om de relatie tussen onze modellen en routes te laten werken zoals gewenst.

Stap 2 — Specificeren van Geneste Routes en Associaties voor het Oudermodel

Rails heeft al de belongs_to associatie ingesteld in ons Post model, dankzij het :references trefwoord in het rails generate scaffold commando, maar om die relatie goed te laten functioneren moeten we ook een has_many associatie specificeren in ons Shark model. We moeten ook wijzigingen aanbrengen in de standaard routing die Rails ons heeft gegeven om de berichtenresources de kinderen te maken van de haairesources.

Om de has_many associatie toe te voegen aan het Shark model, open app/models/shark.rb met nano of je favoriete editor:

nano app/models/shark.rb

Voeg de volgende regel toe aan het bestand om de relatie tussen haaien en berichten vast te stellen:

class Shark < ApplicationRecord
  has_many :posts
  validates :name, presence: true, uniqueness: true
  validates :facts, presence: true
end

Eén ding om hierover na te denken is wat er gebeurt met berichten zodra een bepaalde haai wordt verwijderd. We willen waarschijnlijk niet dat de berichten geassocieerd met een verwijderde haai blijven bestaan in de database. Om ervoor te zorgen dat alle berichten geassocieerd met een bepaalde haai worden geëlimineerd wanneer die haai wordt verwijderd, kunnen we de dependent optie opnemen bij de associatie.

Voeg de volgende code toe aan het bestand om ervoor te zorgen dat de destroy actie op een bepaalde haai alle bijbehorende berichten verwijdert:

class Shark < ApplicationRecord
  has_many :posts , dependent: :destroy
  validates :name, presence: true, uniqueness: true
  validates :facts, presence: true
end

Nadat je deze wijzigingen hebt aangebracht, sla het bestand op en sluit het. Als je nano gebruikt, kun je dit doen door op CTRL+X, Y, en dan ENTER te drukken.

Vervolgens, open je config/routes.rb bestand om de relatie tussen je resourcevolle routes te wijzigen:

nano config/routes.rb

Het bestand ziet er momenteel als volgt uit:

Rails.application.routes.draw do
  resources :posts 
  resources :sharks

  root 'sharks#index'
  # Voor details over de DSL die beschikbaar is in dit bestand, zie http://guides.rubyonrails.org/routing.html
end

De huidige code legt een onafhankelijke relatie tussen onze routes vast, terwijl we eigenlijk een afhankelijke relatie willen uitdrukken tussen haaien en hun bijbehorende berichten.

Laten we onze routeverklaring bijwerken om :sharks de ouder van :posts te maken. Werk de code in het bestand bij zodat het er als volgt uitziet:

Rails.application.routes.draw do
  resources :sharks do
    resources :posts
end
  root 'sharks#index'
  # Voor details over de DSL die beschikbaar is in dit bestand, zie http://guides.rubyonrails.org/routing.html
end

Sla het bestand op en sluit het wanneer je klaar bent met bewerken.

Met deze wijzigingen op hun plaats kun je doorgaan met het bijwerken van je posts-controller.

Stap 3 — De Posts Controller Bijwerken

De associatie tussen onze modellen geeft ons methoden die we kunnen gebruiken om nieuwe berichtinstanties aan te maken die zijn gekoppeld aan specifieke haaien. Om deze methoden te gebruiken, moeten we ze toevoegen aan onze posts-controller.

Open het bestand van de posts-controller:

nano app/controllers/posts_controller.rb

Het bestand ziet er momenteel zo uit:

class PostsController < ApplicationController
  before_action :set_post, only: [:show, :edit, :update, :destroy]

  # KRIJG /berichten
  # KRIJG /berichten.json
  def index
    @posts = Post.all
  end

  # KRIJG /berichten/1
  # KRIJG /berichten/1.json
  def show
  end

  # KRIJG /berichten/new
  def new
    @post = Post.new
  end

  # KRIJG /berichten/1/edit
  def edit
  end

  # VERZEND /berichten
  # VERZEND /berichten.json
  def create
    @post = Post.new(post_params)

    respond_to do |format|
      if @post.save
        format.html { redirect_to @post, notice: 'Post was successfully created.' }
        format.json { render :show, status: :created, location: @post }
      else
        format.html { render :new }
        format.json { render json: @post.errors, status: :unprocessable_entity }
      end
    end
  end

  # PATCH/PUT /berichten/1
  # PATCH/PUT /berichten/1.json
  def update
    respond_to do |format|
      if @post.update(post_params)
        format.html { redirect_to @post, notice: 'Post was successfully updated.' }
        format.json { render :show, status: :ok, location: @post }
      else
        format.html { render :edit }
        format.json { render json: @post.errors, status: :unprocessable_entity }
      end
    end
  end

  # VERWIJDER /berichten/1
  # VERWIJDER /berichten/1.json
  def destroy
    @post.destroy
    respond_to do |format|
      format.html { redirect_to posts_url, notice: 'Post was successfully destroyed.' }
      format.json { head :no_content }
    end
  end

  private
    # Gebruik callbacks om gemeenschappelijke instellingen of beperkingen tussen acties te delen.
    def set_post
      @post = Post.find(params[:id])
    end

    # Vertrouw nooit op parameters van het enge internet, sta alleen de witte lijst toe.
    def post_params
      params.require(:post).permit(:body, :shark_id)
    end
end

Net als onze sharks-controller werken de methoden van deze controller met instanties van de bijbehorende klasse Post. Bijvoorbeeld, de methode nieuw maakt een nieuwe instantie van de klasse Post aan, de methode index pakt alle instanties van de klasse, en de methode set_post gebruikt find en params om een specifieke post te selecteren op basis van id. Als we echter willen dat onze post-instanties geassocieerd worden met specifieke shark-instanties, dan moeten we deze code aanpassen, aangezien de klasse Post momenteel opereert als een onafhankelijke entiteit.

Onze aanpassingen zullen gebruikmaken van twee dingen:

• De methoden die voor ons beschikbaar werden toen we de belongs_to en has_many associaties aan onze modellen toevoegden. Specifiek hebben we nu toegang tot de build methode dankzij de has_many associatie die we hebben gedefinieerd in ons Shark model. Met deze methode kunnen we een verzameling post objecten maken die geassocieerd zijn met een bepaald haaienobject, met behulp van de shark_id vreemde sleutel die bestaat in onze posts database.
• De routes en route-helpers die beschikbaar werden toen we een geneste posts route creëerden. Voor een volledige lijst van voorbeeldroutes die beschikbaar worden wanneer u geneste relaties tussen resources creëert, zie de Rails documentatie. Voor nu is het voldoende voor ons om te weten dat voor elke specifieke haai — laten we zeggen sharks/1 — er een bijbehorende route zal zijn voor berichten die verband houden met die haai: sharks/1/posts. Er zullen ook route-helpers zijn zoals shark_posts_path(@shark) en edit_sharks_posts_path(@shark) die verwijzen naar deze geneste routes.

In het bestand zullen we beginnen met het schrijven van een methode, get_shark, die zal worden uitgevoerd vóór elke actie in de controller. Deze methode zal een lokale @shark instantievariabele maken door een haai-instantie te vinden op basis van shark_id. Met deze variabele beschikbaar voor ons in het bestand, zal het mogelijk zijn om berichten te relateren aan een specifieke haai in de andere methoden.

Boven de andere private methoden onderaan het bestand, voeg de volgende methode toe:

. . . 
private
  def get_shark
@shark = Shark.find(params[:shark_id])
end
  # Gebruik callbacks om gemeenschappelijke instellingen of beperkingen tussen acties te delen.
. . . 

Vervolgens, voeg de overeenkomstige filter toe aan de bovenkant van het bestand, vóór de bestaande filter:

class PostsController < ApplicationController
  before_action :get_shark

Dit zorgt ervoor dat get_shark wordt uitgevoerd vóór elke actie die in het bestand is gedefinieerd.

Vervolgens kunt u deze @shark instantie gebruiken om de index methode te herschrijven. In plaats van alle instanties van de Post klasse te pakken, willen we dat deze methode alle postinstanties retourneert die zijn geassocieerd met een specifieke haai-instantie.

Wijzig de index methode om er zo uit te zien:

. . .
  def index
    @posts = @shark.posts
  end
. . .

De new methode zal een soortgelijke herziening nodig hebben, aangezien we willen dat een nieuwe postinstantie wordt geassocieerd met een specifieke haai. Om dit te bereiken, kunnen we gebruikmaken van de build methode, samen met onze lokale @shark instantievariabele.

Wijzig de new methode om er zo uit te zien:

. . . 
  def new
    @post = @shark.posts.build
  end
. . . 

Deze methode creëert een postobject dat is geassocieerd met de specifieke haai-instantie uit de get_shark methode.

Vervolgens zullen we de methode aanpakken die het meest nauw verbonden is met new: create. De create methode doet twee dingen: het bouwt een nieuwe postinstantie met behulp van de parameters die gebruikers hebben ingevoerd in het new formulier, en als er geen fouten zijn, slaat het die instantie op en gebruikt een routehelper om gebruikers door te verwijzen naar waar ze de nieuwe post kunnen zien. In geval van fouten rendert het opnieuw de new template.

Update de create methode om er zo uit te zien:

  def create
    @post = @shark.posts.build(post_params)

        respond_to do |format|
         if @post.save  
            format.html { redirect_to shark_posts_path(@shark), notice: 'Post was successfully created.' }
            format.json { render :show, status: :created, location: @post }
         else
            format.html { render :new }
            format.json { render json: @post.errors, status: :unprocessable_entity }
      end
    end
  end

Kijk vervolgens naar de update methode. Deze methode gebruikt een @post instantievariabele, die niet expliciet is ingesteld in de methode zelf. Waar komt deze variabele vandaan?

Bekijk de filters bovenaan het bestand. De tweede, automatisch gegenereerde before_action filter geeft een antwoord:

class PostsController < ApplicationController
  before_action :get_shark
  before_action :set_post, only: [:show, :edit, :update, :destroy]
  . . .

De update methode (net als show, edit, en destroy) gebruikt een @post variabele vanuit de set_post methode. Die methode, vermeld onder de get_shark methode met onze andere private methoden, ziet er momenteel zo uit:

. . . 
private
. . . 
  def set_post
    @post = Post.find(params[:id])
  end
. . .

In lijn met de methoden die we elders in het bestand hebben gebruikt, moeten we deze methode aanpassen zodat @post verwijst naar een specifiek exemplaar in de verzameling van posts die geassocieerd is met een bepaalde haai. Houd hierbij de build methode in gedachten – dankzij de associaties tussen onze modellen, en de methoden (zoals build) die beschikbaar zijn voor ons door middel van die associaties, maakt elk van onze post instanties deel uit van een verzameling objecten die geassocieerd is met een bepaalde haai. Het is dus logisch dat bij het opvragen van een bepaalde post, we de verzameling posts opvragen die geassocieerd is met een bepaalde haai.

Update set_post om er zo uit te zien:

. . . 
private
. . . 
  def set_post
    @post = @shark.posts.find(params[:id])
  end
. . .

In plaats van het vinden van een specifiek exemplaar van de hele Post klasse op basis van id, zoeken we in plaats daarvan naar een overeenkomstige id in de verzameling van posts die geassocieerd is met een bepaalde haai.

Met die methode bijgewerkt, kunnen we kijken naar de update en destroy methoden.

De update methode maakt gebruik van de @post instantievariabele van set_post, en gebruikt deze samen met de post_params die de gebruiker heeft ingevoerd in het edit formulier. In het geval van succes, willen we dat Rails de gebruiker terugstuurt naar de index weergave van de berichten die zijn geassocieerd met een bepaalde haai. In het geval van fouten zal Rails de edit template opnieuw renderen.

In dit geval is de enige wijziging die we moeten maken aan de redirect_to instructie, om succesvolle updates te behandelen. Werk het bij zodat het doorverwijst naar shark_post_path(@shark), wat zal doorverwijzen naar de index weergave van de berichten van de geselecteerde haai:

. . . 
  def update
    respond_to do |format|
      if @post.update(post_params)
        format.html { redirect_to shark_post_path(@shark), notice: 'Post was successfully updated.' }
        format.json { render :show, status: :ok, location: @post }
      else
        format.html { render :edit }
        format.json { render json: @post.errors, status: :unprocessable_entity }
      end
    end
  end
. . .

Hierna zullen we een soortgelijke wijziging aanbrengen in de destroy methode. Werk de redirect_to methode bij om verzoeken door te verwijzen naar shark_posts_path(@shark) in het geval van succes:

. . . 
  def destroy
    @post.destroy
     respond_to do |format|
      format.html { redirect_to shark_posts_path(@shark), notice: 'Post was successfully destroyed.' }
      format.json { head :no_content }
    end
  end
. . .

Dit is de laatste wijziging die we zullen maken. Je hebt nu een posts controller bestand dat er zo uitziet:

class PostsController < ApplicationController
  before_action :get_shark
  before_action :set_post, only: [:show, :edit, :update, :destroy]

  # GET /berichten
  # GET /berichten.json
  def index
    @posts = @shark.posts
  end

  # GET /berichten/1
  # GET /berichten/1.json
  def show
  end

  # GET /berichten/new
  def new
    @post = @shark.posts.build
  end

  # GET /berichten/1/edit
  def edit
  end

  # POST /berichten
  # POST /berichten.json
  def create
    @post = @shark.posts.build(post_params)

        respond_to do |format|
         if @post.save  
            format.html { redirect_to shark_posts_path(@shark), notice: 'Post was successfully created.' }
            format.json { render :show, status: :created, location: @post }
         else
            format.html { render :new }
            format.json { render json: @post.errors, status: :unprocessable_entity }
      end
    end
  end

  # PATCH/PUT /berichten/1
  # PATCH/PUT /berichten/1.json
  def update
    respond_to do |format|
      if @post.update(post_params)
        format.html { redirect_to shark_post_path(@shark), notice: 'Post was successfully updated.' }
        format.json { render :show, status: :ok, location: @post }
      else
        format.html { render :edit }
        format.json { render json: @post.errors, status: :unprocessable_entity }
      end
    end
  end

  # DELETE /berichten/1
  # DELETE /berichten/1.json
  def destroy
    @post.destroy
    respond_to do |format|
      format.html { redirect_to shark_posts_path(@shark), notice: 'Post was successfully destroyed.' }
      format.json { head :no_content }
    end
  end

  private

   def get_shark
     @shark = Shark.find(params[:shark_id])
   end
    # Gebruik callbacks om gemeenschappelijke instellingen of beperkingen tussen acties te delen.
    def set_post
      @post = @shark.posts.find(params[:id])
    end

    # Vertrouw nooit op parameters van het enge internet, sta alleen de whitelist toe.
    def post_params
      params.require(:post).permit(:body, :shark_id)
    end
end

De controller beheert hoe informatie wordt doorgegeven van de weergavesjablonen naar de database en vice versa. Onze controller weerspiegelt nu de relatie tussen onze Shark– en Post-modellen, waarbij berichten worden geassocieerd met specifieke haaien. We kunnen doorgaan met het aanpassen van de weergavesjablonen zelf, waar gebruikers berichtinformatie over specifieke haaien zullen invoeren en wijzigen.

Stap 4 — Weergaven aanpassen

Onze revisies van de weergavesjablonen zullen het wijzigen van de sjablonen omvatten die betrekking hebben op berichten, en ook het aanpassen van onze haaien show-weergave, omdat we willen dat gebruikers de berichten zien die zijn geassocieerd met specifieke haaien.

Laten we beginnen met het fundament van ons berichtsjabloon: de gedeeltelijke formulier die opnieuw wordt gebruikt in meerdere berichtsjablonen. Open dat formulier nu:

nano app/views/posts/_form.html.erb

In plaats van alleen het post-model door te geven aan de form_with-formulierhelper, zullen we zowel de shark– als post-modellen doorgeven, waarbij post wordt ingesteld als een gekoppeld bron.

Verander de eerste regel van het bestand om er zo uit te zien, waarbij de relatie tussen onze haai- en postbronnen wordt weerspiegeld:

<%= form_with(model: [@shark, post], local: true) do |form| %>
. . . 

Verwijder vervolgens het gedeelte dat het shark_id van de gerelateerde haai vermeldt, aangezien dit geen essentiële informatie is in de weergave.

Het voltooide formulier, inclusief onze bewerkingen van de eerste regel en zonder het verwijderde shark_id-gedeelte, ziet er als volgt uit:

<%= form_with(model: [@shark, post], local: true) do |form| %>
  <% if post.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(post.errors.count, "error") %> prohibited this post from being saved:</h2>

      <ul>
      <% post.errors.full_messages.each do |message| %>
        <li><%= message %></li>
      <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= form.label :body %>
    <%= form.text_area :body %>
  </div>

  <div class="actions">
    <%= form.submit %>
  </div>
<% end %>

Sla het bestand op en sluit het wanneer je klaar bent met bewerken.

Open vervolgens de weergave index, die de berichten zal tonen die zijn geassocieerd met een bepaalde haai:

nano app/views/posts/index.html.erb

Dankzij het rails generate scaffold-commando heeft Rails het grootste deel van de sjabloon gegenereerd, compleet met een tabel die het body-veld van elk bericht en de bijbehorende shark toont.

Net zoals de andere code die we al hebben aangepast, behandelt deze sjabloon berichten echter als onafhankelijke entiteiten, terwijl we gebruik willen maken van de associaties tussen onze modellen en de collecties en helpermethoden die deze associaties ons geven.

In de inhoud van de tabel, voer de volgende updates uit:

Ten eerste, update post.shark naar post.shark.name, zodat de tabel het naamveld van de bijbehorende haai zal bevatten, in plaats van identificatiegegevens over het haai-object zelf:

. . . 
  <tbody>
    <% @posts.each do |post| %>
      <tr>
        <td><%= post.body %></td>
        <td><%= post.shark.name %></td>
. . . 

Vervolgens, wijzig de Show doorverwijzing zodat gebruikers rechtstreeks naar de show weergave voor de bijbehorende haai worden geleid, aangezien ze waarschijnlijk een manier willen hebben om terug te navigeren naar de oorspronkelijke haai. We kunnen gebruik maken van de @shark instantievariabele die we hier in de controller hebben ingesteld, aangezien Rails instantievariabelen die in de controller zijn aangemaakt beschikbaar maakt voor alle weergaven. We zullen ook de tekst voor de link veranderen van Show naar Show Shark, zodat gebruikers beter begrijpen wat de functie ervan is.

Update deze regel naar het volgende:

. . . 
  <tbody>
    <% @posts.each do |post| %>
      <tr>
        <td><%= post.body %></td>
        <td><%= post.shark.name %></td>
        <td><%= link_to 'Show Shark', [@shark] %></td>

In de volgende regel willen we ervoor zorgen dat gebruikers worden gerouteerd naar het juiste geneste pad wanneer ze een bericht willen bewerken. Dit betekent dat ze niet worden doorverwezen naar posts/post_id/edit, maar naar sharks/shark_id/posts/post_id/edit. Hiervoor zullen we de shark_post_path routing helper en onze modellen gebruiken, die Rails zal behandelen als URL’s. We zullen ook de tekst van de link bijwerken om de functie ervan duidelijker te maken.

Update de regel Edit zodat deze er als volgt uitziet:

. . . 
  <tbody>
    <% @posts.each do |post| %>
      <tr>
        <td><%= post.body %></td>
        <td><%= post.shark.name %></td>
        <td><%= link_to 'Show Shark', [@shark] %></td>
        <td><%= link_to 'Edit Post', edit_shark_post_path(@shark, post) %></td>

Vervolgens voegen we een soortgelijke wijziging toe aan de Destroy link, waarbij we de functie in de string bijwerken en onze shark en post resources toevoegen:

. . . 
  <tbody>
    <% @posts.each do |post| %>
      <tr>
        <td><%= post.body %></td>
        <td><%= post.shark.name %></td>
        <td><%= link_to 'Show Shark', [@shark] %></td>
        <td><%= link_to 'Edit Post', edit_shark_post_path(@shark, post) %></td>
        <td><%= link_to 'Destroy Post', [@shark, post], method: :delete, data: { confirm: 'Are you sure?' } %></td>

Tot slot, onderaan het formulier, willen we de New Post pad bijwerken om gebruikers naar het juiste geneste pad te leiden wanneer ze een nieuw bericht willen maken. Werk de laatste regel van het bestand bij om gebruik te maken van de new_shark_post_path(@shark) routing helper:

. . . 
<%= link_to 'New Post', new_shark_post_path(@shark) %>

Het afgewerkte bestand zal er als volgt uitzien:

<p id="notice"><%= notice %></p>

<h1>Posts</h1>

<table>
  <thead>
    <tr>
      <th>Body</th>
      <th>Shark</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @posts.each do |post| %>
      <tr>
        <td><%= post.body %></td>
        <td><%= post.shark.name %></td>
        <td><%= link_to 'Show Shark', [@shark] %></td>
        <td><%= link_to 'Edit Post', edit_shark_post_path(@shark, post) %></td>
        <td><%= link_to 'Destroy Post', [@shark, post], method: :delete, data: { confirm: 'Are you sure?' } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<br>

<%= link_to 'New Post', new_shark_post_path(@shark) %>

Sla het bestand op en sluit het af wanneer je klaar bent met bewerken.

De andere wijzigingen die we zullen maken aan de berichtweergaven zullen niet zo talrijk zijn, aangezien onze andere weergaven het form-gedeelte gebruiken dat we al hebben bewerkt. We zullen echter de link_to-verwijzingen in de andere berichtsjablonen willen bijwerken om de wijzigingen die we hebben aangebracht in ons form-gedeelte te weerspiegelen.

Open app/views/posts/new.html.erb:

nano app/views/posts/new.html.erb

Werk de link_to-verwijzing onderaan het bestand bij om gebruik te maken van de shark_posts_path(@shark)-helper:

. . . 
<%= link_to 'Back', shark_posts_path(@shark) %>

Sla het bestand op en sluit het af wanneer je klaar bent met deze wijziging.

Open vervolgens het edit-sjabloon:

nano app/views/posts/edit.html.erb

Naast het Back-pad zullen we Show bijwerken om onze geneste resources weer te geven. Verander de laatste twee regels van het bestand zodat ze er zo uitzien:

. . . 
<%= link_to 'Show', [@shark, @post] %> |
<%= link_to 'Back', shark_posts_path(@shark) %>

Sla het bestand op en sluit het af.

Open vervolgens het show-sjabloon:

nano app/views/posts/show.html.erb

Voer de volgende wijzigingen door aan de Edit– en Back-paden onderaan het bestand:

. . .
<%= link_to 'Edit', edit_shark_post_path(@shark, @post) %> |
<%= link_to 'Back', shark_posts_path(@shark) %>

Sla het bestand op en sluit het af wanneer je klaar bent.

Als laatste stap willen we de show-weergave voor onze haaien bijwerken zodat berichten zichtbaar zijn voor individuele haaien. Open dat bestand nu:

nano app/views/sharks/show.html.erb

Onze wijzigingen hier zullen onder andere het toevoegen van een Posts-sectie aan het formulier en een Add Post-link onderaan het bestand omvatten.

Onder de Facts voor een gegeven haai, zullen we een nieuwe sectie toevoegen die door elke instantie in de verzameling van berichten gaat die aan deze haai zijn gekoppeld, waarbij de body van elk bericht wordt uitvoergegeven.

Voeg de volgende code toe onder de Facts-sectie van het formulier, en boven de omleidingen onderaan het bestand:

. . .
<p>
  <strong>Facts:</strong>
  <%= @shark.facts %>
</p>

<h2>Posts</h2>
<% for post in @shark.posts %>
    <ul>
      <li><%= post.body %></li>
  </ul>
<% end %>

<%= link_to 'Edit', edit_shark_path(@shark) %> |
. . . 

Vervolgens, voeg een nieuwe omleiding toe om gebruikers in staat te stellen een nieuw bericht toe te voegen voor deze specifieke haai:

. . .
<%= link_to 'Edit', edit_shark_path(@shark) %> |
<%= link_to 'Add Post', shark_posts_path(@shark) %> |
<%= link_to 'Back', sharks_path %>

Sla het bestand op en sluit het wanneer je klaar bent met bewerken.

Je hebt nu wijzigingen aangebracht in de modellen, controllers en views van je applicatie om ervoor te zorgen dat berichten altijd worden geassocieerd met een bepaalde haai. Als laatste stap kunnen we enkele validaties toevoegen aan ons Post-model om consistentie te garanderen in de gegevens die naar de database worden opgeslagen.

Stap 5 — Validaties toevoegen en de applicatie testen

In Stap 5 van Hoe bouw je een Ruby on Rails applicatie, heb je validaties toegevoegd aan je Shark model om uniformiteit en consistentie te waarborgen in de gegevens die worden opgeslagen in de sharks database. We zullen nu een soortgelijke stap nemen om garanties te bieden voor de posts database.

Open het bestand waarin je Post model is gedefinieerd:

nano app/models/post.rb

Hier willen we ervoor zorgen dat posts niet leeg zijn en dat ze geen duplicaat inhoud bevatten die andere gebruikers hebben gepost. Voeg hiervoor de volgende regel toe aan het bestand:

class Post < ApplicationRecord
  belongs_to :shark
  validates :body, presence: true, uniqueness: true
end

Sla het bestand op en sluit het wanneer je klaar bent met bewerken.

Met deze laatste wijziging ben je klaar om je migraties uit te voeren en de applicatie te testen.

Voer eerst je migraties uit:

rails db:migrate

Start vervolgens je server. Als je lokaal werkt, kun je dit doen door het volgende uit te voeren:

rails s

Als je aan een ontwikkelingsserver werkt, voer dan in plaats daarvan het volgende commando uit:

rails s --binding=your_server_ip

Navigeer naar de hoofdmap van je applicatie op http://localhost:3000 of http://je_server_ip:3000.

De vereiste Rails-projecttutorial leidde je door het toevoegen en bewerken van een Grote Witte haaienitem. Als je geen verdere haaien hebt toegevoegd, zal de startpagina van de applicatie er zo uitzien:

Klik op Weergeven naast de naam van de Great White. Dit brengt je naar de weergave van deze haai. Je ziet de naam van de haai en zijn feiten, en een Berichten kop zonder inhoud. Laten we een bericht toevoegen om dit deel van het formulier in te vullen.

Klik op Bericht toevoegen onder de Berichten kop. Dit brengt je naar de bericht index weergave, waar je de kans krijgt om Nieuw bericht te selecteren:

Dankzij de authenticatiemechanismen die je hebt ingesteld in Stap 6 van Hoe maak je een Ruby on Rails applicatie, kan het zijn dat je wordt gevraagd om te authenticeren met de gebruikersnaam en wachtwoord die je hebt aangemaakt in die Stap, afhankelijk van of je een nieuwe sessie hebt aangemaakt of niet.

Klik op Nieuw bericht, dit brengt je naar je bericht nieuw sjabloon:

In het Lichaam veld, typ “Deze haaien zijn eng!”

Klik op Bericht aanmaken. Je wordt omgeleid naar de index weergave voor alle berichten die bij deze haai horen:

Met onze berichtbronnen die werken, kunnen we nu onze gegevensvalidaties testen om ervoor te zorgen dat alleen gewenste gegevens naar de database worden opgeslagen.

Vanuit de index weergave, klik op Nieuw bericht. In het Lichaam veld van het nieuwe formulier, probeer opnieuw “Deze haaien zijn eng!” in te voeren:

Klik op Post maken. U zult de volgende foutmelding zien:

Klik op Terug om terug te keren naar de hoofdpagina van de berichten.

Om onze andere validatie te testen, klik opnieuw op Nieuwe post. Laat de post leeg en klik op Post maken. U zult de volgende foutmelding zien:

Met uw geneste resources en validaties correct werkend, heeft u nu een werkende Rails applicatie die u kunt gebruiken als uitgangspunt voor verdere ontwikkeling.

Conclusie

Met uw Rails applicatie op zijn plaats, kunt u nu werken aan zaken zoals styling en het ontwikkelen van andere front-end componenten. Als u meer wilt leren over routing en geneste resources, is de Rails documentatie een geweldige plek om te beginnen.

Om meer te leren over het integreren van front-end frameworks met uw applicatie, bekijk Hoe u een Ruby on Rails project opzet met een React frontend.