20201229(화)

레일즈 재밌는데?ㅋㅋㅋ

2020-12-29

1. 학습 날짜

2020-12-29

2. 학습 시간

10:30 ~ 22:30

3. 학습 범위 및 주제

루비온레일즈 컨트롤러, 라우팅

4. 학습 목표

페펙트 루비 온 레일즈 6, 7장

5. 과제 제출

6. 상세 학습 내용

상태관리란 여러 개의 페이지 사이에서 정보를 유지하기 위한 구조다. 쉽게 말하면 로그인의 유무에 따라 클라이언트 페이지에서 동작이 다르게 되야한다는 것이다. 로그인하지 않았을 때는 오른쪽 위에 로그인 이라는 버튼이 나오고, 로그인했을 때는 로그아웃이 나오게 하는 것도 상태관리의 일종이다. 웹서버는 이런 상태를 유지하기 위해 몇가지 기법을 쓰는데, 그 중 가장 간단한 건 쿠키를 이용하는 것이다. 원칙적으로 서버는 클라이언트의 쿠키를 소유하면 안된다. 하지만 특정한 경우, 상태관리를 할 때는 임시적으로나마 쿠키를 서버에서 갖는게 허용이 된다. 서버는 클라이언트의 쿠키를 확인하고 클라이언트의 상태를 확인한다. 그리고 그에 맞는 응답을 준다. 쿠키 보다 더 좋은 방법은 세션을 사용하는 것이다. 세션도 기본적으로 쿠키를 이용한다. 하지만 세션은 그 쿠키를 저장하는 곳을 정할 수 있다.
- 그렇다면 왜 상태관리를 이렇게 쿠키 또는 세션을 이용해서 해야하는가? 이유는 간단하다. http 프로토콜의 무상태 프로토콜 원칙 때문이다. 무상태 프로토콜이란 상태를 유지하지 않는 프로토콜이다. 즉 http의 태생상 상태관리가 되지 않기 때문에 서버에서는 조금 귀찮은 방법으로 상태관리를 해야 한다는 것.
- 쿠키를 이용하는 방법, 세션을 이용하는 방법은 각각이 cookies, session 이라는 메서드를 이용한다.
필터
- 필터란 액션 메서드가 실행되기 이전과 이후에 부가 처리를 위해 사용되는 기능이다.
- 이전에 모델을 학습할 때는 DB관련 작업 전후 처리를 하기 위해 callBack 이라는 기능이 있었던 것처럼 컨트롤러에는 필터 기능이 있다.
- 필터는 상속이 가능하다.
- 모든 컨트롤러는 ApplicationController 를 상속 받는다. 따라서 모든 컨트롤러에서 사용하고 싶다? 이 Application 에다가 필터를 만들어 주면 된다.
- 어떤 메서드에만 필터를 적용하고, 적용하지 않을 수 있는 기능이 있다. only 와 except 를 이용하면 된다.
라우팅
- RESTful 인터페이스는 REST의 특징을 가진 라우트를 말한다. REST는 네트워크의 모든 컨텐츠를 URL로 표현하는 것이다. 그리고 이러한 URL에 HTTP, GET, POST, PATCH DELETE 등의 방법으로 접근한ㄷ. 한마디로 REST는 무엇(리소스)를 어떻게 (HTTP 메서드)할지 표현하는 것이다.
- RESTful 인터페이스를 잘 사용하면 통일감 있고 의미가 명확한 URL 설계가 가능하다.
- rails는 원칮걱으로 RESTful 인터페이스를 기반으로 라우트를 설계한다.
  - form_with, link_to 등의 뷰 헬퍼는 RESTful 인터페이스를 전제로 설계되었다.
- RESTful 인터페이스를 정의할 때는 routes.rb 에서 resources 메서드를 호출하면 된다.
- resources 는 CRUD 할 수 있는 정보라고 생각하면 된다.
  - 이렇게 생성하고 이후에 쉘에 rails routes 라고 명령을 입력하면 각 라우팅 정보가 나온다.
- 복수말고 단수의 resource도 존재한다.
  - 이 메서드는 하나의 리소스를 관리하는 RESTful 인터페이스를 만들 수 있다.
  - 아직 실습해보지는 않았지만, 로그인 한 상태의 유저가 자신의 프로필을 보고 싶을 때, /users/profile/user.id 처럼 프로필 인덱스에서 자신의 id를 이용해 자기의 프로필을 찾는건 너무 멍청해 보인다.
  - 아마 이런 경우에 resource 를 사용하는게 아닌가 싶다.
- constrains 기능으로 라우트매개 변수에 제약 조건을 걸 수 있다.
  - 제약은 기본적으로 모델, 컨트롤러 모든 곳에서 다 할수있다.
  - 그렇다면 어디서 이 제약을 거는게 좋은걸까?
- as 를 이용해 URL 헬퍼 이름을 변경할 수 있다.
- 중첩 구조를 이용할 수 있다. 가령 book 이라는 모델에는 reviews 가 has_many, belongs_to 로 묶여있다. 우리는 당연히 book과 관련된 URL으로 reviews를 찾아야 할 것이다 라고 생각한다. (/books/:book_id/reviews) 이렇게 해주고 싶을 때 사용하는게 중첩구조의 resources 다.
  - 이렇게 중첩으로 바꾸면 기존에 만들었던 뷰 들을 다 수정해야 한다.

7. 오늘 학습 내용에 대한 개인적인 총평

흠.. 오늘은 나쁘지 않게 학습한 것 같다. 내일은 더 열심히 해봐야겠다.

8. 다음 학습 계획

7장 복습, 회원가입, 로그인, 로그아웃 등의 기능이 있는 사이트를 간단하게 구조 생각하고 만들어보

Previous20201228(월)Next20201230(수)

Last updated 4 years ago

Was this helpful?

2020-12-29

1. 학습 날짜

2020-12-29

2. 학습 시간

10:30 ~ 22:30

3. 학습 범위 및 주제

루비온레일즈 컨트롤러, 라우팅

4. 학습 목표

페펙트 루비 온 레일즈 6, 7장

5. 과제 제출

6. 상세 학습 내용

상태관리란 여러 개의 페이지 사이에서 정보를 유지하기 위한 구조다. 쉽게 말하면 로그인의 유무에 따라 클라이언트 페이지에서 동작이 다르게 되야한다는 것이다. 로그인하지 않았을 때는 오른쪽 위에 로그인 이라는 버튼이 나오고, 로그인했을 때는 로그아웃이 나오게 하는 것도 상태관리의 일종이다. 웹서버는 이런 상태를 유지하기 위해 몇가지 기법을 쓰는데, 그 중 가장 간단한 건 쿠키를 이용하는 것이다. 원칙적으로 서버는 클라이언트의 쿠키를 소유하면 안된다. 하지만 특정한 경우, 상태관리를 할 때는 임시적으로나마 쿠키를 서버에서 갖는게 허용이 된다. 서버는 클라이언트의 쿠키를 확인하고 클라이언트의 상태를 확인한다. 그리고 그에 맞는 응답을 준다. 쿠키 보다 더 좋은 방법은 세션을 사용하는 것이다. 세션도 기본적으로 쿠키를 이용한다. 하지만 세션은 그 쿠키를 저장하는 곳을 정할 수 있다.

그렇다면 왜 상태관리를 이렇게 쿠키 또는 세션을 이용해서 해야하는가? 이유는 간단하다. http 프로토콜의 무상태 프로토콜 원칙 때문이다. 무상태 프로토콜이란 상태를 유지하지 않는 프로토콜이다. 즉 http의 태생상 상태관리가 되지 않기 때문에 서버에서는 조금 귀찮은 방법으로 상태관리를 해야 한다는 것.
쿠키를 이용하는 방법, 세션을 이용하는 방법은 각각이 cookies, session 이라는 메서드를 이용한다.

필터

필터란 액션 메서드가 실행되기 이전과 이후에 부가 처리를 위해 사용되는 기능이다.
이전에 모델을 학습할 때는 DB관련 작업 전후 처리를 하기 위해 callBack 이라는 기능이 있었던 것처럼 컨트롤러에는 필터 기능이 있다.
필터는 상속이 가능하다.
모든 컨트롤러는 ApplicationController 를 상속 받는다. 따라서 모든 컨트롤러에서 사용하고 싶다? 이 Application 에다가 필터를 만들어 주면 된다.
어떤 메서드에만 필터를 적용하고, 적용하지 않을 수 있는 기능이 있다. only 와 except 를 이용하면 된다.

라우팅

RESTful 인터페이스는 REST의 특징을 가진 라우트를 말한다. REST는 네트워크의 모든 컨텐츠를 URL로 표현하는 것이다. 그리고 이러한 URL에 HTTP, GET, POST, PATCH DELETE 등의 방법으로 접근한ㄷ. 한마디로 REST는 무엇(리소스)를 어떻게 (HTTP 메서드)할지 표현하는 것이다.
RESTful 인터페이스를 잘 사용하면 통일감 있고 의미가 명확한 URL 설계가 가능하다.
rails는 원칮걱으로 RESTful 인터페이스를 기반으로 라우트를 설계한다.
- form_with, link_to 등의 뷰 헬퍼는 RESTful 인터페이스를 전제로 설계되었다.
RESTful 인터페이스를 정의할 때는 routes.rb 에서 resources 메서드를 호출하면 된다.
resources 는 CRUD 할 수 있는 정보라고 생각하면 된다.
- 이렇게 생성하고 이후에 쉘에 rails routes 라고 명령을 입력하면 각 라우팅 정보가 나온다.
복수말고 단수의 resource도 존재한다.
- 이 메서드는 하나의 리소스를 관리하는 RESTful 인터페이스를 만들 수 있다.
- 아직 실습해보지는 않았지만, 로그인 한 상태의 유저가 자신의 프로필을 보고 싶을 때, /users/profile/user.id 처럼 프로필 인덱스에서 자신의 id를 이용해 자기의 프로필을 찾는건 너무 멍청해 보인다.
- 아마 이런 경우에 resource 를 사용하는게 아닌가 싶다.
constrains 기능으로 라우트매개 변수에 제약 조건을 걸 수 있다.
- 제약은 기본적으로 모델, 컨트롤러 모든 곳에서 다 할수있다.
- 그렇다면 어디서 이 제약을 거는게 좋은걸까?
as 를 이용해 URL 헬퍼 이름을 변경할 수 있다.
중첩 구조를 이용할 수 있다. 가령 book 이라는 모델에는 reviews 가 has_many, belongs_to 로 묶여있다. 우리는 당연히 book과 관련된 URL으로 reviews를 찾아야 할 것이다 라고 생각한다. (/books/:book_id/reviews) 이렇게 해주고 싶을 때 사용하는게 중첩구조의 resources 다.
- 이렇게 중첩으로 바꾸면 기존에 만들었던 뷰 들을 다 수정해야 한다.

7. 오늘 학습 내용에 대한 개인적인 총평

흠.. 오늘은 나쁘지 않게 학습한 것 같다. 내일은 더 열심히 해봐야겠다.

8. 다음 학습 계획

7장 복습, 회원가입, 로그인, 로그아웃 등의 기능이 있는 사이트를 간단하게 구조 생각하고 만들어보