Shall We Django? [4]

1/ Django Template Language

데이터를 저장하는 데 쓰일 model이 일차적으로 준비됐다. 이제 당면한 목표는 두 개다. 하나는 데이터베이스의 내용을 웹페이지에 렌더링하는 것이고, 다른 하나는 웹페이지에서 바로 내용을 입력하는 기능을 넣는 것이다. 이번 포스팅에서는 전자를 다룰 예정이다.

 

데이터베이스의 내용을 사용자가 접하는 웹페이지란 결국 templates다. 즉 html을 다뤄야 한다. 그러나, 어떻게? 어떻게 해야 데이터베이스의 자료를 html로 끌고 올 수 있을까? a 태그를 써서 하이퍼링크라도 달아야 할까?

 

우리는 데이터베이스를 Python 객체로써 다루고 있다. 이러한 객체를 조작하기 위해서는 역시 Python 파일이 필요하다. 우리는 templates에 연관된 Python 파일을 알고 있다. 바로 views다. apps/views.py의 내용을 다음과 같이 작성하였다.

 

from django.shortcuts import render
from .models import Wiki

def greetings(request):
    return render(request, 'greetings.html')

def main_page(request):
    wiki_list = Wiki.objects.order_by('-updated_at')
    context = {
        "wiki_list": wiki_list,
    }
    return render(request, 'main_page.html', context)

 

같은 디렉토리 내의 models.py로부터 Wiki(데이터베이스 model)를 import하였고, 동시에 새로운 웹페이지 template과 연결할 다른 view 함수인 main_page를 정의하였다. 당연히 main_page 함수가 대상으로 하는 main_page.html도 apps/templates 디렉토리에 생성하였고, urls.py 파일에도 등록하였다.

 

 

이제 main_page 함수의 내용을 들여다보자. wiki_list라는 변수는 Wiki의 내부 클래스(inner class)인 objects의 메서드(method) order_by()의 반환값이며, 이때 메서드의 인자는 '-updated_at'이다.

 

그렇다면 갑자기 튀어나온 이 objects란 무엇일까? Django에서는 모든 model에 Manager라는 데이터베이스 쿼리 작업 인터페이스(1)를 제공한다. 이 Manager의 기본 이름이 바로 objects이며, objects 내부에는 데이터베이스를 조작할 수 있는 많은 메서드들이 정의되어 있다. order_by()도 그런 objects의 메서드 중 하나다. 이름에서 드러나듯이 특정 기준으로 정렬을 하는 메서드이며, 'id'라고 하면 id의 오름차순으로 정렬되고 '-id'라고 하면 내림차순으로 정렬된다. 즉 wiki_list는 수정된 시각을 기준으로 내림차순 정렬하여 그 목록을 받은 변수인 셈이다.

 

아래의 context라는 dictionary는 render 함수가 목적 html로 운반할 정보다. 단순한 상수를 전달할 수도 있으며, 지금 코드와 같이 데이터베이스의 정보를 전달할 수도 있다.

 

이제 전달된 정보를 해당 html에서 수령할 차례다. 이때 쓰이는 것이 DTL(Django Template Language)인데… 생각해보면 의아하다. 데이터를 전달한 것까지는 좋은데, html은 프로그래밍 언어도 아닌데 어떻게 전달된 정보를 수령할까?

 

이것이 바로 render 함수가 하는 일이다. 단순히 html의 내용을 띄우는 것만이라면 브라우저도 할 수 있다. 하지만 Django라는 웹 프레임워크는 데이터베이스의 정보와 같은 동적 데이터(2)를 처리할 수 있도록 추가적인 툴을 지원하는 것. render 함수는 context를 html 파일로 보낸다기보다 자신이 들고 있다가 html 파일에 기입된 DTL을 바탕으로 동적 데이터를 적용한 뒤 그 결과물을 렌더링하는 것이다.(3)

 

이제 html 파일에 DTL을 삽입해보자.

 

<ul>
  {% for wiki in wiki_list %}
    <li><a href="/wiki/{{ wiki.id }}/">{{ wiki.subject }}</a></li>
  {% endfor %}
</ul>

 

unordered lists에 웬 Python-like한 구문이 들어가 있는 것을 볼 수 있다. 이것이 DTL이다. 딱 보면 for-each문처럼 wiki_list 내부의 항목들을 순회할 것처럼 생겼다. 실제로도 그렇다. 이외에도 DTL의 구성요소는 많지만 필요할 때마다 언급하겠다.

 

위의 내용에 간단한 스타일을 적용시킨 뒤 해당 페이지를 렌더링한 모습은 다음과 같다.

 

데이터베이스의 튜플이 하나뿐이기에 리스트도 한 개뿐이다

 

아주 허섭하지만 그래도 뭔가 만들어진 것을 볼 수 있다!

 

심지어 링크까지 걸려 있다. 싱글벙글 웃으며 저 링크를 클릭하면,

 

 

404 error가 우리를 반긴다. (당연하지만) 아직 해당 페이지에 대한 세부 설정이 이루어지지 않았기 때문이다.

 

다음 시간에는 저 링크를 클릭하면 해당 튜플의 content가 나타나게 만들어 볼 예정이다.

 

 

+/ 240320 돌아보기

1) Shall We Django 프로젝트를 시즌제로 굴려볼 생각이다. 시즌 1은 이번 달 안에 끝내고 싶지만 잘 될지는 모르겠다. 시즌 1은 그대로 개인 위키의 프레임을 만드는 것까지 하고, 시즌 2는 클론 코딩을 해보려 한다.

왜 하필 클론 코딩인가? 프로젝트를 진행하면서 느낀 점이 있다. 내가 Django의 아주 일부분만을 보고 있다는 점이다. 외부에서의 강력한 요구가 삽입되면 그에 맞춰 기능을 구현해야 하고, 그 과정에서 Django는 물론 웹에 대한 이해가 넓어질 거라고 기대하고 있다. 지금은 그저 튜토리얼에 불과한 느낌이 든다. 튜토리얼도 중요하지만 결국엔 본 게임을 위한 거니까. 클론 코딩을 통해 전체상을 인식해나갔으면 좋겠다. 그 다음에 뭔가 새로운 시도를 해볼 수도 있고!

 

2) 비슷한 일을 이미 해본 사람이 학습하는 과정과 해당 분야를 처음 접하는 사람이 학습하는 과정은 다르다. 전자는 자신의 지식과 매칭시키며 빠르게 전진할 수 있지만, 후자는 그랬다간 놓치는 게 너무 많아진다. 원래 빠르게 치고 나가려 했던 이 프로젝트가 조금 (많이) 느려진 것에는 그런 이유도 있다. 물론 다른 이유도 있지만…….

 

 

 

*/ 질문 상자

1) 인터페이스란 무엇일까? 유저 인터페이스, GUI 혹은 CLI… 그리고 보다 엄밀한(혹은 내가 그렇게 느끼는) 영역에서의 인터페이스란 API와 추상 클래스의 부분집합으로써 인터페이스가 있다. 명확한 정의와 분류가 필요하다. 동시에 OOP에 대한 이해가 요구된다.

2) 사용자의 행위에 따라 변경될 수 있는 데이터를 동적 데이터라고 생각하고 있는데 맞는지 모르겠다. 검증 필요.

3) 확언하듯이 말했는데 지금의 내 이해가 그렇다는 것이고, 실제로 그런지는 검증이 필요하다.