Django : URLs

지금까지 어느정도 윤곽은 잡아놨고, url의 사용방법 변경을 변경하게 되면서 앞의 내용을 왜 배웠나 싶지만.. 모든건 이유가 있다고 생각한다. 어떻게 발전해왔고 어떤 의미를 뜻하는지 천천히 쫓아간다면 오히려 이해가 되기 때문이다. 그러나 유독 django는 배우면 '하지만!! 더 좋은게 있죠?' 의 느낌은 떨쳐내긴 어렵다.. 그래도 하나씩 알아가는건 재밌는 것 같다.

---

Django URLs

계속 다뤄온 url을 왜 다시 다루게 되었을까? urls의 정의를 떠올려보자. URL dispatcher (운항 관리자, 분배기)로 URL 패턴을 정의하고 패턴이 일치하는 요청을 처리할 view 함수를 연결(매핑) 하는 것. 

기존 Django URLs의 역할로 요청을 받으면 urls에서 경로를 찾아서 해당하는 app의 views를 실행한다

 

그림으로 깔끔하게 설명할 수 있다. 우리는 project dir 내부에서 urls 파일에 패턴을 추가해가며 view 함수와 매핑시키고 있었다. 하지만 해봐야 2-3개까지밖에 안했다. 

네이버에서만 봐도 메인 페이지의 일부에서 9개 이상의 app을 확인할 수 있다

 

이 모든 url 패턴을 한 페이지에서 관리하기란 쉽지 않을 것이다. 그러면 간단하게 app에서 url 패턴을 관리하면 좋지 않을까? 이를 'App URL mapping' 이라고 한다.

이때 문제점도 같이 발견된다. 각자의 app에서 url을 관리하는데, url 패턴의 이름이 겹치는 경우가 올 것이다. 물론 신경쓰면 가능하지만 위의 9개 경우에서도 어디에 어떤게 써져있는지 보면서 할 것인가? 물론 app의 views를 import 할 때, 다른 네이밍으로 해결할 수 있긴 하다. 하지만 나눠져서 구분을 못한다면 결국 하나에 합쳐져 관리하는 것과 다를 것이 있을까?

 

이를 해결하기위해 url을 각자의 app에서 관리하게 하는 것이다.

project의 urls가 각자 app의 urls를 거쳐간다

 

이렇게 되므로써 url의 구조가 크게 변화하게 된다. 코드로 한번 살펴보자

굉장히 추가한게 많아보이지만 결국, include로 연결해주고 각 app의 urls.py 파일을 생성해 분할 해준다고 생각하면 편하다

 

각 app urls.py 내부에 views를 연결시켜줘야하는 것도 잊으면 안된다.

.은 현재 폴더를 의미한다

 

views.py가 같은 폴더내에 존재하기 때문에 따로 경로를 입력할 필요 없이 ' . ' 을 사용하면 쉽게 탐색할 수 있다.

include( )

 

: 프로젝트 내부 앱들의 URL을 참조할 수 있도록 매핑하는 함수로 URL의 일치하는 부분까지 잘라내고 남은 문자열 부분은 후속 처리를 위해 include된 URL로 전달하는 역할을 한다.

대충 include 함수가 실행되는 과정...

 

include 함수에 마우스 커서를 올려두고 Ctrl + 좌클릭으로 함수 내부를 열어볼 수 있는데, 위와 같이 생겼다. 아직 모르는 함수들과 명령어들이 많아서 해석하기는 어렵지만, arg 인자로 넘겨진 것이 app의 urls가 문자열로 전달된 것을 따라가서 어떻게 흐르는지만 알면 된다. 너무 깊게 들어가지는 말자!

 

include의 함수를 사용했고, 각자의 app에서 urls를 관리할 수 있게 되었다. 근데, 이렇게 urls가 바뀌게 된다면 html에서 경로도 바꾸어주어야하고 해당 주소를 사용한 모든 파일을 변경해주어야 한다. 그러면 각 URL에 사용가능한 대명사 네임텍을 붙여준다면 쓰기 쉽지 않을까? 마치 청소도구에 이름을 붙여주는 것처럼 말이다.

 

Naming URL patterns

 

: URL에 이름을 지정하는것으로 path 함수의 name 인자를 정의해서 사용한다.

사용하는 방법은 굉장히 간단하게, path 함수의 키워드 인자로 명시해주기만 하면 된다.

이제는 url 태그를 추가해 URL 패턴의 이름과 일치하는 절대 경로 주소를 반환한다

이후 개발자도구로 확인해보면 이전에 작성했던것과 동일한 것을 확인 할 수 있다

 

경로가 만들어지는 과정은 위와 같다.

 

해당 경로는 settings에서 설정해주었던 패턴과 각 app에서 설정한 경로를 더해서 연결되기 때문에 개발자도구에서 위처럼 출력되는 것이다.

 

그럼 이제 이름은 붙여주었다. 근데 name이 Larva라고 가정하면 세상 모든 애벌레가 나오듯, 단순히 이름만으로 완벽하게 분리할 수 없다. 다른 앱에도 같은 url 이름이 같으면 혼란이 올 수 있기 때문인데, 이는 앞에 성을 붙임으로서 해결할 수 있다. 나도 CodingLarva가 된 것처럼 말이다.

 

성을 붙여주는 것도 단순하다. 위에서 include 함수를 잠시 들여다 볼 때, 성을 붙일 수 있는 설정이 있다. 다만 app_name 이 URL 패턴의 네임 스페이스를 결정해주기 때문에 직접 함수를 수정하지 않는한 다른 변수명을 사용할 수 없다. 

성은 app의 이름을 따라가는 것이 좋다

url 형태의 최종 버전이다

---

url의 최종 버전을 보고나니 이제 큰 문제 없구나 싶다. 그리고 django를 back-end로 얘기하며 정리중이지만, 실제론 풀스택이다. 왜냐면 html도 직접 다루는걸 지금까지 봐왔을 것이다. 이정도면 django도 강력한게 아닐까? (아니다)