Category Archives: 허접프로그래머

[Ruby] IntelliJ에서 Rails를 이용한 간단한 방명록 만들어보기

rails_logo

요즘 열심히 레일즈 공부를 하고 있습니다. 사실 열심은 아닌것 같네요. 백문이 불여일견 뭔가 한번 해보는게 좋지 않을까 싶어 간단한 방명록을 혼자 만들어보기를 해보기로 하였습니다. 그 과정을 기록해 볼테니 저같은 시작하시는분들에게 참고 자료가 될 수 있다면 좋겠네요.

이 기록은 Rails기반의 개발이 가능한 제트브레인사의 IntelliJ 또는 RubyMine기반에서 개발한다는것을 가정하고 기록하고자 합니다. 또한 맥기반에서 개발하고 있기에 윈도우 환경과는 차이가 조금 있을수도 있습니다.

making_guestbook_using_rails_1

IntelliJ를 실행한 뒤에 새로운 프로젝트를 생성하기 위해 Create New Project를 선택합니다.

making_guestbook_using_rails_2

Ruby 플러그인을 선택한 뒤에 적절한 프로젝트를 생성합니다. 저는 그냥 대충 guestbook이라고 만들어보겠습니다.

making_guestbook_using_rails_3

이번엔 적절한 SDK를 선택해줍니다. 아무것도 없다면 Configure에 들어가 설치되어있는 Ruby를 선택하여 추가해 주면 됩니다.

making_guestbook_using_rails_4

왼쪽의 Ruby on Rails를 선택한 다음에 적절한 Rails Version을 선택해 줍니다. 아무것도 없을 경우 Install Rails Gem…을 선택하여 적절한 Rails를 설치해주면 됩니다.

making_guestbook_using_rails_5

이제 프로젝트가 세팅되고 자동으로 bundle install까지 실행됩니다.

making_guestbook_using_rails_6

이런식으로 “Your bundle is complete!”라는 문구가 보이면 프로젝트의 초기화가 끝난것입니다.

making_guestbook_using_rails_7

오른쪽 상단의 플레이 모양 버튼을 누르면 WEBrick 기반의 서버가 시작됩니다. 정상적으로 실행된다면 콘솔에 보이는것과 같은 로그가 출력됩니다. 이제 브라우저를 통해서 http://localhost:3000 에 접속해 보겠습니다.

making_guestbook_using_rails_8

위와 같은 기본 페이지를 볼 수 있습니다. 여기서 무언가 친절한 설명이 나오고 있군요. 저 설명대로 진행을 해보겠습니다.

making_guestbook_using_rails_9

New – Run Rails Generator를 실행해 봅니다. 간단하게 Option – G를 눌러도 됩니다.

making_guestbook_using_rails_10

컨트롤러를 먼저 만들까 모델을 먼저 만들까 고민을 많이 했습니다만, 가이드의 순서가 뭔가 의미가 있지 않을까(?) 생각되어 모델부터 만들어 보겠습니다. 검색을 통해 빠르게 무엇을 생성할것인지를 선택할 수 있습니다.

making_guestbook_using_rails_13

Generate arguments 의 내용을 참고하여 필요하다고 생각되는 항목을 적어보았습니다. 사용자의 정보인 name, email이 있고 내용을 수정 삭제하기 위한 password와 방명록 글 내용인 content를 추가하였습니다. 여기서 예시에 [ ]를 보고 대괄호를 해줘야 하는줄 알았는데 Optional의 의미더군요;;

Rails는 단수복수의 구분이 매우 중요합니다. 모델을 생성할 때 단수로 생성한것을 주의깊게 봐두세요.

making_guestbook_using_rails_12

오류 없이 정상적으로 필요한 것들이 생성되었습니다. DB 마이그레이션 작업을 수행하여보겠습니다. 기본적으로 Development환경에서의 데이터베이스 설정은 sqlite로 구성되어있습니다. 아쉬운데로 그냥 진행해보겠습니다.

making_guestbook_using_rails_16

rake 라는 명령을 사용하여 데이터베이스 마이그레이션을 진행하게 되는데 Tools – Run Rake Task…메뉴를 통해 실행할 수 있습니다. 단축키는 Option + R 입니다.

making_guestbook_using_rails_17

마이그레이션 시점을 선택할 수 있습니다. 일단 하나밖에 없군요. 그냥 latest migration을 선택하도록 하겠습니다.

making_guestbook_using_rails_14_2

이번에는 컨트롤러를 만들어보았습니다. 여기서 주목할 점은 컨트롤러의 이름이 복수형이라는것 그리고 액션에 7개를 추가하였습니다. 이 7개의 액션은 외울필요가 있습니다. 이후에 나올 라우팅 설정에서 리소스라는것과 연결되게 됩니다. 각각은 다음을 담당하게 됩니다.

  • index : 방명록의 모든 글을 보여줍니다.
  • new : 방명록에 새로운 글을 작성하는 HTML폼을 보여줍니다.
  • create : 방명록에 새로운글을 추가합니다. 데이터베이스에 INSERT 하는 작업을 수행합니다.
  • show : 방명록에 작성된 글중 하나의 특정한 글을 보여줍니다.
  • edit : 방명록에 작성된 글 중 하나의 특정한 글을 수정하는 HTML폼을 보여줍니다.
  • update : 특정한 글의 내용을 수정합니다. 데이터베이스에 UPDATE 하는 작업을 수행합니다.
  • destroy : 방명록에 작성된 글 중 하나의 특정한 글을 삭제합니다.

making_guestbook_using_rails_18

여기에 보이는 버튼들을 이용하여 서버를 종료하거나 재시작할 수 있습니다. 재시작하기 전에 라우팅 설정을 좀 살펴보겠습니다. 라우팅 설정파일은 config/routes.rb 파일을 참고하시면 됩니다. 여기서 외부의 어떤 요청을 어떤 컨트롤러에 연결해줄것인가에 대한 정의를 하게 됩니다.

making_guestbook_using_rails_19

음… IntelliJ께서 친절하게 자동으로 뭔가를 추가해주셨네요. 밑에 post/*들은 테스트로 해봤다가 남아있는 잔재입니다; 위의 내용을 모두 삭제하고 다음으로 변경합시다.

Guestbook::Application.routes.draw do
  resources "posts"
end

이제 서버를 새시작하고 http://localhost:3000/posts 에 접속해 봅시다.

making_guestbook_using_rails_20

/posts 로의 요청이 자연스럽게 PostsController의 index 액션을 타고 결과적으로 index 뷰가 출력되었습니다. 저 resources 설정이 자동으로 필요한 라우트 설정을 추가해 줍니다. 이를 확인해 보려면 rake routes를 실행해 보는 방법이 있습니다. Option + R 을 눌러 rake 실행창을 열고 routes를 실행해 봅시다.

   Prefix Verb   URI Pattern               Controller#Action
    posts GET    /posts(.:format)          posts#index
          POST   /posts(.:format)          posts#create
 new_post GET    /posts/new(.:format)      posts#new
edit_post GET    /posts/:id/edit(.:format) posts#edit
     post GET    /posts/:id(.:format)      posts#show
          PATCH  /posts/:id(.:format)      posts#update
          PUT    /posts/:id(.:format)      posts#update
          DELETE /posts/:id(.:format)      posts#destroy

Process finished with exit code 0

이것을 천천히 봐보시면 알 수 있지만 /posts/* 패스를 이용하여 기존에 생성했던 7개의 메소드에 연결해주는것을 볼 수 있습니다. 위의 내용을 해석해 보면 다음을 알 수 있습니다.

  • GET /posts 를 요청하면 방명록에 작성된 모든 글을 보여준다. (디비 SELECT)
  • POST /posts 를 요청하면 방명록에 새로은 글을 추가한다. (디비 INSERT)
  • GET /posts/new 를 요청하면 방명록에 새로운 글을 작성할 수 있는 HTML 폼을 보여준다.
  • GET /posts/:id/edit 를 요청하면 방명록에 기존에 작성된 글을 수정할 수 있는 HTML 폼을 보여준다.
  • PATCH 또는 PUT /posts/:id 를 요청하면 방명록에 기존에 작성된 글의 내용을 수정한다. (디비 UPDATE)
  • DELETE /posts/:id 를 요청하면 방명록에 기존에 작성된 글을 삭제한다. (디비 DELETE)

여기서 재미있는 점이 한가지 있는데 Prefix에 있는 값들을 레일즈안에서 마치 메소드처럼 호출하여 사용할 수 있습니다. (posts_path, new_post_path 등.. 뒤에서 설명하겠습니다) 이제 위의 기능들이 하나하나 동작하도록 고쳐보겠습니다.

일단 방명록이라고 하면 대체적으로 상단에 글쓰기 폼이 있고 그 밑으로 기존에 작성된 글들이 리스트되어 보여지는 형태입니다. 그러므로 이 프로젝트에서는 GET /posts/new 페이지는 없어도 괜찮을지 모르겠습니다. 그러면 먼저 GET /posts 에 글쓰기 폼을 추가해 보겠습니다. app/views/posts/index.html.erb의 내용을 다음과 같이 수정하였습니다. 레일즈에서 제공하는 Form Helper를 사용하였습니다. HTML 쌩코딩을 하고싶었지만 일반 HTML폼으로는 GET/POST이외에는 구현하기 어렵기 때문에 이것을 사용하는것이 좋을것 같습니다.

<h1>Guestbook List</h1>
<%=form_for :post, url: posts_path, method: :post do |f| %>
    Name : <%=f.text_field :name  %><br>
    Email : <%=f.text_field :email  %><br>
    Password : <%=f.password_field :password  %><br>
    <%=f.text_area :content  %>
    <%=f.submit %>
<% end %>

그리고 http://localhost:3000/posts에 들어가면 다음과 같은 화면을 볼 수 있습니다.

making_guestbook_using_rails_21

새로운 글 작성에 필요한 폼이 만들어졌습니다. 위에서 확인했었던 routes 값과 비교해 보면 POST 메소드로 posts_path에 요청을 날리게 되어있습니다.(form의 action과 method값 확인) 여기서의 posts는 routes 결과 첫번째 줄에 정의된 값입니다. 거기 정의되어있는 URI Pattern값을 반환하게 됩니다. 즉 /posts 를 반환하게 됩니다.

rake routes의 결과에서 가장 앞단에 있는 Prefix의 값은 URI Pattern에 정의되어있는 값과 매칭됩니다. 하지만 Prefix라는 명칭에서 알 수 있듯이 접두사로 쓰이게 되며 뒤에 _path 또는 _url을 붙여서 사용합니다. _path를 붙인 경우 주소의 패스값을 반환하게 되고 _url을 붙이게 되면 도메인, 포트등의 모든 주소를 붙인값을 반환하게 됩니다.

<%=posts_path %> 라고 하였으니 도메인이나 포트 정보가 제외된 형태 즉, /posts 를 반환합니다.

폼의 제출 버튼을 누르면 POST /posts 를 수행하게 될테니 routes 정보를 볼때 posts#create가 실행될것이라는것을 알 수 있습니다. create 액션을 만들어보겠습니다.

def create
  post = Post.new
  post.name = params[:post][:name]
  post.email = params[:post][:email]
  post.password = params[:post][:password]
  post.content = params[:post][:content]
  post.save
  redirect_to posts_path
end

POST로 넘어온 파라미터로 그대로 넘기는것이 가능한 이유는 HTML폼의 필드들의 name의 값과 디비(모델)의 필드명이 동일하기때문에 가능한 부분입니다.이제 http://localhost:3000/posts 에 진입하여 폼을 채우고 “제출” 버튼을 눌러봅시다.

아무런 오류없이 다시 글쓰기 폼이 보이는것을 확인할 수 있습니다. 리다이렉트가 잘 되는군요. 이제 저장된 결과를 출력해 봅시다. 먼저 PostsController (app/controllers에 존재)에 index 액션을 수정합니다.

def index
  @posts = Post.all
end

posts/index.html.erb 뷰에는 form 밑에 다음을 추가해 줍니다.

<% @posts.each do |post| %>
<div>
    <p><%=post.name%> (<%=post.email%>)</p>
    <p><%=post.content%></p>
</div>
<% end %>

이제 수정된 결과를 확인하러 가봅시다.

making_guestbook_using_rails_23 making_guestbook_using_rails_24

작성한 글이 잘 출력되어 보여지는군요. 이제 수정과 삭제 버튼을 만들어 보겠습니다. 위의 erb내용을 다음과 같이 좀 더 업데이트 해봅시다.

<% @posts.each do |post| %>
<div>
    <p>
        <%=post.id%>
        <%=link_to "수정", edit_post_path(post.id) %>
        <%=link_to "삭제", post, :method => :delete %></p>
    <p><%=post.name%> (<%=post.email%>)</p>
    <p><%=post.content%></p>
</div>
<p></p>
<% end %>

posts/edit.html.erb 뷰파일을 다음과 같이 수정합니다.

<h1>Guestbook Edit</h1>
<%=form_for :post, url: post_path(@post), method: :patch do |f| %>
    Name : <%=f.text_field :name  %><br>
    Email : <%=f.text_field :email  %><br>
    Password : <%=f.password_field :password  %><br>
    <%=f.text_area :content  %>
    <%=f.submit %>
<% end %>

PostsController의 edit, update, destroy 액션의 내용을 추가합니다.

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

def update
  post = Post.find(params[:id])
  post.name = params[:post][:name]
  post.email = params[:post][:email]
  post.password = params[:post][:password]
  post.content = params[:post][:content]
  post.save
  redirect_to posts_path
end

def destroy
  post = Post.find(params[:id])
  post.destroy
  redirect_to posts_path
end

이제 기본적으로 새로운글을 추가, 수정, 삭제가 가능한 방명록(이라고 부르긴 힘들겠지만)을 만들어 보았습니다. 비밀번호 대조를 통해서 수정시 뭔가 체크를 하는 기능을 구현하고자 password를 만들었지만 그부분은 패스하겠습니다^^;

[Ruby] Rails 라우팅

1. 레일즈 라우터의 목적

레일즈 라우터는 외부로부터 들어오는 URL을 인식하고 컨트롤러의 액션으로 보내주는 역할을 합니다. 이를 이용하여 개발중인 뷰에서 하드코딩할 필요 없이 패스와 URL을 생성하는것 역시 가능합니다.

1.1 URL을 코드로 연결하기

당신의 레일즈 어플리케이션이 외부로부터 다음과 같은 요청을 받을 수 있습니다.

GET /patients/17

레일즈는 라우터에게 매칭되는 컨트롤러 액션이 있는지 물어보게 됩니다. 첫번째로 매칭된 라우트 정의는 다음과 같습니다.

get '/patients/:id', to: 'patients#show'

이 요청은 patients 컨트롤러의 show 액션에 { id: ’17’ } 이라는 파라미터와 함께 전달됩니다.

1.2 코드에서 패스와 URL을 생성하기

마찬가지로 패스들과 URL들을 생성하는것도 가능합니다. 위의 라우트 정의를 다음과 같이 바꾸었다고 가정하겠습니다.

get '/patients/:id', to: 'patients#show', as: 'patient'

그리고 당신의 어플리케이션은 컨트롤러의 코드에 다음을 포함합니다.

@patient = Patient.find(17)

그리고 다음의 코드가 컨트롤러에 대응되는 뷰에 존재합니다.

<%= link_to 'Patient Record', patient_path(@patient) %>

위의 과정을 통해 라우터는 /patients/17 이라는 패스를 생성합니다. 이는 당신의 코드의 복잡성을 줄여주고 이해하기 쉽게 만들어줍니다. 라우트 헬퍼를 이용할 때 id가 특정될 필요가 없습니다.

2. 리소스 라우팅 : 레일즈 기본

리소스 라우팅은 index, show, new, edit, create, update, destroy 액션들을 일일이 정의하는것 대신 일반적으로 사용되는 라우트 설정들을 매우 빠르게 정의하는것을 가능케 합니다. 리소스 라우팅은 이러한 정의를 단지 한줄의 코드로 가능하게 해줍니다.

2.1 웹상의 리소스들

브라우저들은 레일즈에 GET, POST, PATCH, PUT, DELETE와 같은 특정 HTTP 메소드를 사용한URL 요청을 통해 페이지를 요청합니다. 각각의 메소드들은 리소스들의 특정 기능을 실행하기 위한 요청이 됩니다. 리소스 라우트는 다양한 요청을 하나의 컨트롤러에 정의된 액션들에 매핑을 해줍니다.

당신의 레일즈 어플리케이션에서 다음과 같은 요청을 받았다고 가정하겠습니다.

DELETE /photos/17

이는 라우터에 질의후 컨트롤러의 액션들에 매핑해주게 됩니다. 첫번째로 매칭된 라우트 정의가 다음과 같을 경우

resources :photos

레일즈는 photos 컨트롤러의 destroy 메소드에 { id: ’17’ } 파라미터와 함께 요청을 전달해 주게 됩니다.

2.2 CRUD (Create, Read, Update, Delete), HTTP메소드, 액션

레일즈에서 리소스 라우트는 HTTP 메소드와 URL을 통해 컨트롤러의 액션에 매핑해 주는 기능을 제공해 줍니다. 컨벤션에의해 각각의 액션은 특정 데이터베이스 CRUD 작업에 매핑됩니다. 라우팅 파일에 다음의 한줄의 설정만으로 구현 가능합니다.

resources :photos

당신의 어플리케이션의 Photos 컨트롤러에 다음과 같은 7개의 다른 라우트 설정이 생성됩니다.

HTTP Method Path Action Used for
GET /photos index 모든 사진을 보여줍니다.
GET /photos/new new 새로운 사진을 등록하기 위한 HTML 폼을 보여줍니다.
POST /photos create 새로운 사진을 생성합니다.
GET /photos/:id show 특정 한개의 사진을 보여줍니다.
GET /photos/:id/edit edit 사진 정보를 수정하기 위한 HTML 폼을 보여줍니다.
PATCH/PUT /photos/:id update 사진 정보를 수정합니다.
DELETE /photos/:id destroy 특정 사진을 삭제합니다.

레일즈 라우트는 정의된 순서에 따라 매치를 하게 됩니다. get ‘photos/poll’ 액션 라우트 설정 위에 :photos 리소스가 정의 되어있을 경우 :photo 리소스에 먼저 매치가 되는 문제가 발생하게 됩니다. 이를 해결하기 위해서는 get 설정을 리소스 정의보다 위에 정의하여 먼저 매치되도록 하여야 합니다.

2.3 패스, URL 헬퍼

리소스 라우트를 생성하면 당신의 어플리케이션의 컨트롤러에 몇개의 헬퍼를 사용가능하게 됩니다. resource :photos 정의가 되어있다고 가정하겠습니다.

  • photos_path 는 /photos 를 반환합니다.
  • new_photo_path 는 /photos/new 를 반환합니다.
  • edit_photo_path(:id) 는 /photos/:id/edit 를 반환합니다. (edit_photo_path(10) 의 경우 /photos/10/edit 를 반환)
  • photo_path(:id) 는 /photos/:id 를 반환 (photo_path(10) 는 /photos/10 을 반환)

이러한 헬퍼들에 대응되는 _url 헬퍼들도 존재합니다. (예: photos_url) URL 헬퍼의 경우 패스 헬퍼와 조금 다르게 현재 호스트, 포트와 패스의 prefix를 포함한 값을 반환합니다.

2.4 다수의 리소스를 한번에 정의하기

한개 이상의 리소스를 생성할 필요가 있을 경우 한번의 resource: 호출로 해결할 수 있습니다.

resources :photos, :books, :videos

위의 정의는 정확하게 다음과 동일한 작업을 수행합니다.

resources :photos
resources :books
resources :videos

2.5 단일 리소스

때때로 클라이언트가 참조할 ID 없이도 접근 가능한 리소스가 필요할 수 있습니다. 예를 들면 /profile 에 접속하면 항상 현재 접속한 유저의 프로필을 보여줄 필요가 있을 경우가 있습니다. 이런 경우 단일 리소스 정의를 사용하여 /profile/:id 대신에 /profile 에 show 액션을 호출하도록 할 수 있습니다.

get 'profile', to: 'users#show'

문자열을 통한 매칭의 경우 Controller#Action 의 형태를 띄지만 심볼을 이용하여 정의하면 액션에 직접적으로 넘겨주게 됩니다.

resource :users do
  get 'profile', to: :show
end

# 또는 다음의 방법도 가능
get 'profile', to: :show, controller: 'users'

다음은 단일 리소스 설정 방법입니다. (단수로 지정하면 됨)

resource :geocoder

당신의 어플리케이션의 Geocoders 컨트롤러(복수형임)에 다음과 같은 6개의 라우팅 설정이 생성됩니다.

HTTP METHOD Path Action Used for
GET /geocoder/new new Geocoder를 생성하기 위한 HTML 폼을 반환합니다.
POST /geocoder create Geocoder를 생성합니다.
GET /geocoder show 하나뿐인 Geocoder 정보를 반환합니다.
GET /geocoder/edit edit Geocoder 값을 수정하는 HTML 폼을 반환합니다.
PATCH/PUT /geocoder update 하나뿐인 Geocoder 값을 수정합니다.
DELETE /geocoder destroy Geocoder 정보를 수정합니다.

단일 리소스 라우트는 다음과 같은 헬퍼들을 만들어 줍니다.

  • new_geocoder_path 는 /geocoder/new 를 반환합니다.
  • edit_geocoder_path 는 /geocoder/edit 를 반환합니다.
  • geocoder_path 는 /geocoder 를 반환합니다.

복수 리소스처럼 호스트, 포트, 패스정보가 포함되는 _url로 끝나는 헬퍼 역시 제공됩니다.

2.6 컨트롤러 네임스페이스와 라우팅

당신은 네임스페이스 이하에 컨트롤러들을 그룹으로 묶어 제공하고 싶을 수 있습니다. 대부분의 경우 관리 기능의 컨트롤러들을 Admin:: 네임스페이스 하에 둘 수 있습니다. 당신은 이런 컨트롤러들을 app/controllers/admin 이하에 둘 수 있고 라우터 설정에서 그룹으로 묶어서 정의할 수 있습니다.

namespace :admin do
  resources :posts, :comments
end

이 정의는 PostsController와 CommentsController에 대해 필요한 라우트를 생성합니다. Admin::PostsController의 경우 레일즈는 다음을 생성합니다.

HTTP METHOD Path Action Used for
GET /admin/posts index admin_posts_path
GET /admin/posts/new new new_admin_post_path
POST /admin/posts create admin_posts_path
GET /admin/posts/:id show admin_post_path(:id)
GET /admin/posts/:id/edit edit edit_admin_post_path(:id)
PATCH/PUT /admin/posts/:id update admin_post_path(:id)
DELETE /admin/posts/:id destroy admin_post_path(:id)

만약 앞에 붙은 /admin 없이 /posts를 Admin::PostsController로 라우팅하고 싶다면 다음과 같이 할 수 있습니다.

scope module: 'admin' do
  resources :posts, :comments
end

또는 다음의 한줄로도 가능합니다.

resources :posts, module: 'admin'

/admin/posts를 Admin:: 모듈 프리픽스 없이 PostsController에 라우팅하고 싶다면 다음의 방법을 사용할 수 있습니다.

scope '/admin' do
  resources :posts, :comments
end

또는 다음의 한줄 선언으로도 가능합니다.

resources :posts, path: '/admin/posts'

위에서 설명한 각각의 방법들 모두 scope를 사용하지 않고도 같은 효과를 내게 됩니다. 마지막 방법의 경우 PostsController에 매핑됩니다.

2.7 중첩 리소스

이 방법은 다른 리소스에 논리적인 자식으로 리소스를 가지는 방법을 말합니다. 예를 들어 당신의 어플리케이션이 다음의 모델들을 가지고 있다고 가정하겠습니다. (하나의 잡지에 다수의 광고가 붙을 수 있는 상황을 가정)

class Magazine < ActiveRecord::Base
  has_many :ads
end

class Ad < ActiveRecord::Base
  belongs_to :magazine
end

중첩 라우트는 이러한 관계들을 알 수 있게 해줍니다. 이런 경우 라우트 선언은 다음과 같습니다.

resources :magazines do
  resources :ads
end

매거진에 라우트를 추가하는 방법으로 이 선언은 ads로의 요청을 AdsController로 라우팅합니다. magazine에 종속된 ad URL들은 다음과 같습니다.

HTTP METHOD Path Action Used for
GET /magazines/:magazine_id/ads index 특정 매거진에 종속된 모든 광고를 보여줍니다.
GET /magazines/:magazine_id/ads/new new 특정 매거진에 종속된 새로운 광고를 추가하는 HTML 폼을 보여줍니다.
POST /magazines/:magazine_id/ads create 특정 매거진에 종속된 새로운 광고를 추가합니다.
GET /magazines/:magazine_id/ads/:id show 특정 매거진에 종속된 특정 광고를 보여줍니다.
GET /magazines/:magazine_id/ads/:id/edit edit 특정 매거진에 종속된 특정 광고의 정보를 수정하는 HTML 폼을 반환합니다.
PATCH/PUT /magazines/:magazine_id/ads/:id update 특정 매거진에 종속된 특정 광고의 정보를 수정합니다.
DELETE /magazines/:magazine_id/ads/:id destroy 특정 매거진에 종속된 특정 광고를 삭제합니다.

이것들은 magazine_ads_url 또는 edit_magazine_ad_path 와 같은 라우트 헬퍼를 생성합니다. 이러한 헬퍼들은 매거진 인스턴스를 첫번째 인자로 받습니다. (magazine_ads_url(@magazine))

2.7.1 중첩 제한

당신은 중첩 리소스를 다른 중첩된 리소스와 함께 사용할 수 있습니다. 예를 들면 다음과 같습니다.

resources :publishers do
  resources :magazines do
    resources :photos
  end
end

깊은 중첩 리소스의 경우 주소가 길어지고 복잡해 질 수 있습니다. 예를 들면 어플리케이션은 다음과 같은 패스가 생길 수 있습니다.

/publishers/1/magazines/2/photos/3

여기에 대응되는 라우트 헬퍼는 publisher_magazine_photo_url 이 됩니다. 3단계 레벨에 따른 특정한 객체도 필요로 됩니다. 실제로 이러한 상황은 충분히 혼란 스러운 상황입니다. 그러므로 중첩 리소스 선언은 1단계 레벨을 넘는 설정을 하지 않는것을 권장합니다. (영어로 never로 표현)

2.7.2 얕은 중첩

위에서 권장한 깊은 중첩을 피하기 위한 한가지 방법으로 배열을 선언하여 스코프를 특정짓는 방법이 있습니다. 다음과 같이 리소스를 식별하는데 필요한 최소한의 정보만으로 라우팅이 가능하도록 설정하는 방법입니다.

resources :posts do
  resources :comments, only: [:index, :new, :create]
end
resources :comments, only: [:show, :edit, :update, :destroy]

위의 설정을 잘 보면 알 수 있습니다만 특정 코멘트의 show, edit, update, destroy는 posts이하에 있을 필요가 없습니다. comments만의 고유 식별자로 처리가 가능한 부분입니다. 하지만 index, new, create의 경우 posts에 종속적인 데이터로 관리되어야 하는 부분이기에 posts에 종속됩니다.

이러한 방법은 설명이 가능한 라우트와 깊은 라우트간에 균형을 유지하는 느낌을 줍니다. 위의 정의를 손쉽게 할 수 있는 방법으로 :shallow 옵션을 사용하는 방법이 있습니다.

resources :posts do
  resources :comments, shallow: true
end

위의 단순한 설정은 정확하게 먼저 보여드린 복잡한 설정과 동일하게 동작합니다. :shallow 옵션을 부모 리소스에 사용하게 되면 모든 중첩 리소스들에 적용됩니다.

resources :posts, shallow: true do
  resources :comments
  resources :quotes
  resources :drafts
end

비슷하게 shallow 메소드를 사용하게 되면 해당 스코프의 모든 중첩 리소스들에 얕은 중첩이 적용됩니다. 이러한 설정은 위의 정의와 정확하게 동일한 결과를 보여줍니다.

shallow do
  resources :posts do
    resources :comments
    resources :quotes
    resources :drafts
  end
end

위에서 설명한 방법을 커스터마이징하여 특정 스코프를 적용한 얕은 라우트를 정의할 수 있습니다. 패스를 정의하는 파라미터와 함께 :shallow_path 를 정의하면 됩니다.

scope shallow_path: "sekret" do
  resources :posts do
    resources :comments, shallow: true
  end
end

comments 리소스는 다음과 같은 라우팅 정의를 갖게 됩니다.