{% url %} 리버스 관련 질문이 2개 있습니다.

2022-07-14T13:10:48.053Z

0

감사합니다. 두 번째 질문에서

이런 식으로 전달될 때는 url 주소가 넘겨준 인자/follow로 되는 반면,

공식 문서에서는

path('client/<int:id>/', app_views.client, name='app-views-client')

If this app’s URLconf is included into the project’s URLconf under a path such as this:

path('clients/', include('project_name.app_name.urls'))

…then, in a template, you can create a link to this view like this:

{% url 'app-views-client' client.id %}

The template tag will output the string /clients/client/123/.

이런 식으로 suggested_user.username 자리에 전달해 준 client.id라는 인자가 넘겨준 인자/follow처럼 넘겨준 인자/client 가 아니라 client/넘겨준 인자 로 된다는 점이 차이가 있는 점이 궁금합니다. {% url %} 기능의 어떤 부분(함수, 클래스 등...)이 이렇게 '전달되는 인자가 기입되는 부분을 알아서 찾도록 해주는지' 너무 똑똑해서 신기해서요ㅎㅎ 

P.S.미해결 창을 지금 봐서 이전 글들 모두 해결로 변경했습니다  :)

0

URL Reverse에서는 path/re_path에 지정된 URL 문자열을 생성해줍니다.

path("client/<int:pk>/", name="client1") 에 매칭되는 {% url "client1" 1234 %} 에서는 /client/1234/ 문자열이 만들어질테구요.

path("<int:pk>/client/", name="client2") 에 매칭되는 {% url "client2" 1234 %} 에서는 /1234/client/ 문자열이 만들어집니다.

{% url "client1" 1234 %} 와 {% url "client2" 1234 %} 는 URL 문자열이 어떻게 조합되는 지 신경쓰지 않아도, path name과 인자만 넘겨주면 되는 거죠. 우리는 어떤 path를 통해서 처리하는 지에 대해서만 신경쓰면 될 뿐, 나머지 URL 문자열 생성은 장고에서 알아서 해주는 거죠.

그러니 path route가 변경이 되어도
이전 => path("client/<int:pk>/", name="client1") 에 대해 {% url "client1" 1234 %}
이후 => path("client/<int:pk>/view/", name="client1") 에 대해 {% url "client1" 1234 %}

URL Reverse 코드는 바뀌지 않죠. :-)

그래서, 장고 내에서 뷰에 대한 URL 문자열을 모두 URL Reverse를 사용토록 하시면, 보다 간결하고 유연하게 URL 처리를 하실 수 있습니다.

0

감사합니다.