Go Revel Route 정리.고 Revel 루팅 정리

1. GO REVEL 구성,
ROUTE 공부하면서 정리
페이스북 그룹 GOLANG KOREA
HTTPS://WWW.FACEBOOK.COM/GROUPS/GOLANGKO/
----------
1
https://fb.com/me.adunhansa
https://twitter.com/arahansa
http://adunhansa.tistory.com/
ABOUT
CONTACT
SOURCE
1

2. 아라한사
-----------------------
--------------------------------------------
국내에도 브로그래머문화가 확산되기를 바라며 이것저것.. 관심만 많음-.-
슬라이드로 정리를 즐겨하나, 하나의 템플릿으로 돌려쓰기하고있다..;;
1. 작성자 소개 2

3. • 본 문서는 번역을 하긴하되, 정확한 번역도 아니고, 보면서
바로 하는 직역도 아니고.. 그냥 보이는 대로 뜻만 통하는
번역이다. 내용이 중간중간 생략해가면서
속도를 위해, 그리고 매끄러운 읽기를 위하여 (사실은
귀차니즘을 극복치못하고) Revel 문서를 번역할 것이다.
• 필자의 개인적 바램은 개발을 모르는 세살배기 어린애도(?!)
이해할 수 있도록..(은 좀 힘들고) 아무튼 개발상식이 없더라도
최대한 이해할 수 있도록 하는 것이 개인적 바램이다.
중간중간에 쓸데없는 설명이 들어갈 수 있다.
• 폰트&디자인같은 것이 마음에 안 들어 요청이 있다면 바꿀
의향이 있다
문서 성격 3

4. • 자 REVEL 공홈의 순서대로 OVERVIEW 를 보자.
일단 구동 4
• Revel과 프로그램들은
GOPATH laybout 안에
GO line tool 에 정해진된대로
설치되어야 한다.
• 레이아웃설명인데 지난시간에도
좀 한 것 같다. 자세히 알아보자

5. • App 디렉토리
• App 디렉토리는 소스코드와 템플릿을 가진 폴더다.
App 디렉토리 5
app/controller
app/models
app/views
revel 은
모든 템플릿이 app/views 에 있고
모든 컨트롤러는 app/controller 에 있다.
• 그밖에, 만약 원한다면 어플리케이션은 그것의 코드를 정리할 수 있다. Revel 은 app/ 폴더 밑의 모든
디렉토리를 관리하며 변경사항이 감지되면 rebuild 한다. App/밖의 어떤 dependencies 들은 변동되어도
감시되지 않을 것이다. 이것은 개발자가 필요할 때, 재컴파일할 책임이 있다는 것을 말한다.
게다가 Revel 은 구동시에 개발자의 코드를 초기화시키기 위해서 app 내의 init() 메소드를 가진 어떤
패키지도 import 한다.
• The Contollers/init.go 파일은 인터셉터 hook 을 등록하는 관습적인 위치파일이다. Init()의 순서는 같은
패키지의 소스파일들사이에서 명확하지가 안다. 그래서 인터셉터 정의를 하나의 파일에 모으는 것은
개발자로 하여금 그것들이 실행될 순서를 명확하게 정하게 해준다.

6. • Conf 디렉토리
• Conf 디렉토리는 어플리케이션 설정 파일이 있는 곳이다.
두가지 주요 설정 파일이 있는데 하나는
app.conf 이다. 어플리케이션을 위한 주요 설정파일로서, 표준설정 파라미터를 가진다.
Routes 는 경로 정의파일이다.
• message/ 디렉토리는 모든 지역화된 메시지 파일을 가지며
• Public 디렉토리는 웹서버에의해 제공될 정적자원들을 저장하는 곳이다. 일반적으로 이것은
나눠진 세개의 하위 디렉토리를 이미지, css, js 파일들을 위해 가진다.
Conf, message, public 디렉토리 6

7. 컨트롤러 오버뷰 7
• Controller
• 컨트롤러는 *revel.Controller 를 내장하는 아무 타입이다.
• 일반적으로 우측이미지 같이 쓰며 (*revel.Controlelr 는 구조체 struct의 첫번째 타입으로
내장되어야 한다)
• Revel.Controller 는 요청을 위한 context 로, 요청과 응답 데이터를 가진다. Godoc에 자세한
설명이 나와있다. 하지만 여기에 정의가 있다. (helpertype의 정의와 함께!)
•

8. • 컨트롤러 오버뷰도 공홈에는 이정도만
나와있다. 다음에는 route를 보자! 오버뷰 끝!
컨트롤러 오버뷰 8

9. • Routing (경로 설정)
• 경로설정은 conf 폴더의 routes 파일안에 정의된다.
• 기본적 문법은 (메소드) (URL패턴) (Controller.Action) 이다.
• 이 예제는 모든 특징을 보여준다. 그러면 한 줄씩 알아보자. 결국
우리는 특정한 action을 취하는 url을 생성하는 reverse
routing 이 어떻게 이뤄지는 지 알게 될 것이다.
Routing!! 드디어!! 9

10. • Routing (경로 설정)
• 간단 경로 GET /login App.Login
이 간단한 경로는 메소드와 경로의 정확한 매치를 사용한다.
AppController 에서 Login 액션을 적용시킨다.
• Trailing slashes GET /hotels/ Hotels.Index
이 경로는 /hotels 와 /hotels/ 두 가지 경로에서 Hotels.Index를
적용시킨다. Hotels.Index에로의 역경로 는 /를 포함할 것이다.
Trailsing slahes 는 액션들 사이에서 구별짓기 위해 사용해서는
안된다. 간단경로 /login 은 /login/ 에 대한 요청에 매칭될 것이다.
• (필자 주: trailing slash .. 뭐. 그냥 / 있건 없건 같이 처리한다
이말아닌가 모르겠다. )
Routing!! 간단경로와 슬래시 10

11. • URL 파라미터들
• GET /hotels/:id Hotels.Show
• 경로의 부분은 매칭되고 추출될 것이다. :id 변수는 “/”를 제외하고 어떤 것과 매칭
될것이다. 예를 들자면 /hotels/123 이나 /hotels/abc 둘다 이 경로로 루팅될
것이다.
• 액션 메소드 파라미터뿐만 아니라 Controller.Params 맵에서 파라미터를
추출하는 것이 가능할 것이다. 예를 들자면 다음과 같다.
(필자 주: 다양한 부분에서 파라미터 추출이 가능하다)
Routing!! : URL 파라미터 11

12. • 라우터가 와일드카드의 두번째 종류를 인식한다. *파라미터는 경로의 마지막 요소가
되어야 한다. 그리고 이것은 모든 후속 경로요소와 매칭된다. 예를 들자면 이와 같은
경우 우리는 /public/으로 시작하는 모든 경로와 매칭될 수 있다.
• 웹소켓은 다른 요청과 같은 방식으로 루팅되지만 ws 라는 메소드 식별자를
쓴다.웹소켓을 받아주는 액션은 다음같이 될 것이다.
Routing!! * 파라미터, 웹소켓 12

13. • 정적자원관리. Static.Serve의 2가지 파라미터 버전을 위해서 “ 사이에 공백은
허용되지 않는다. 또한 인코딩/csv 때문이기도 하다.
• 정적 자원 디렉토리들을 지원하기 위하여 Revel 은 Static controller 를 가진
static 모듈을 제공하며 이 컨트롤러는 두개의 파라미터를 받는다.
• Prefix(String) – (상대 혹은 절대)자원 루트 경로
• Filepath(String) 요청된 파일의 상대경로
Routing!! 정적자원관리 13

14. • 정적 자원 부분에서 설명했듯이, 루팅은 아마 하나 이상의 파라미터를 액션에
명시한다. 저 위를 예로 보자.
• 제공된 아규먼트들은 그들의 포지션을 사용하여서 파라미터이름으로 바운딩된다.
이러한 경우 리스트 타입 문자열은 첫번째 액션 파라미터의 이름으로 바운딩 된다.
이러한 것들은 다음상황에 유용할 수 있다.
• 비슷한 액션들이 있는 경우
• 같은 일을 하지만 다른 mode로 운영되는 경우
• 같은 일을 하지만 다른 데이터 타입으로 운영되는 경우
Routing!! 고정된 파라미터 14

15. • Routes 를 가지고 있는 모듈들은 두가지 방법으로 임포트 가능하다.
일단 mymodule이 이러한 route 파일을 가지고 있다고 가정하자.
• 첫번째 방법은 routes 파일을 이용해서 있는 그대로의 경로를 불러오는 것이다.
• 이렇게 바로 모듈을 불러오면
/gopher와 /gopher/add의 주소가
바로 임포트 된다.
• 두번째 방법은 prefix된 경로 밑에 임포트 하는 방법
이렇게 하면
/foo/gopher 와 /foo/gopher/add를
가지게 된다
Routing!! 루팅 모듈 15

16. URL 아규먼트 추출은 또한 적용될 액션을 결정하는 데 사용할 수 있다. 컨트롤러와
액션매칭은 대소문자를 구분하지않는다.
• 이 루팅 라인 예제는 다음 루팅경로에 영향을 미친다.
• 비슷하게, 이 예제는 어떤 액션에도 접근한다.
또한 대소문자를 구별하지 않기 때문에 대문자로 써도 같은 액션을 취하게 된다.
• 오토루팅은 특히 리버스 루팅과 결합하여 빠른 액션 적용에 유용하다.
Routing!! 자동 루팅 16

17. • 몇가지 이유로 리버스 루팅을 사용하여 URL을 만들어보는 것은 좋은 연습이다.
• 오탈자 피하기
• 컴파일러가 리버스 루팅이 적절한 숫자와 파라미터 타입을 가지고 있는지 보장하기
• 지역화된 URL이 루트파일을 변화시키기(필자 주 :Localizes URL changes to
one place: the routes file. 라고 써있었는데 뭔말인지..-_-)
• 당신의 어플리케이션을 빌드하자마자, Revel 은 app/routes 패키지를 만들것이고,
양식의 선언과 함께 사용될 것이다.
• 다음의 문장은 URL을 Controller.Action 에 주어진 파라미터와 함께 리턴한다.
다음장에 좀더 복잡한 예제가 있다.
Routing!! 리버스 루팅 17

18. • 다음 슬라이드에서는 루팅에 대해서 배운 것을 실제 revel에서 만든 myapp 을
가지고 일단 좀 만지작 만지작 놀아봐야겠다.. 루팅 예제는 다음과 같다고 하는데
당장 이해는
잘 안된다-.-ㅋ
Routing!! 리버스 루팅 18

19. • 일단 끝. 슬라이드들의 정리를 아마 페이스북 golangkorea 에서 목록화를 시켜둘
Revel 정리 : 끝 19
것같다.

20. 20
THANK YOU !
arahansa
------
------
페북 : https://fb.com/me.adunhansa
트위터 : https://twitter.com/arahansa
블로그: http://adunhansa.tistory.com/