프로젝트 시작
⭐️ 1. 프로젝트 첫 시작!
터미널에서 콘다로 가상환경 만들고.. 파이참으로 넘어와서 다시 가상환경 맞춰주고(가상환경 activate) 해주고, 장고 설치되어 있는지 python -m django --version로 확인하고 설치 안되어 있으면 pip install django 를 통해 장고 깔아주고 django-admin startproject 프로젝트이름 으로 프로젝트 시작함(이때 프로젝트 파일들이 자동생성됨)
⭐️ python manage.py runserver 로 장고 프로젝트가 제대로 동작하는지 확인! (프로젝트 파일내에서 실행해야됨)
💡 django-admin과 manage.py의 차이
django-admin은 장고의 커맨드라인 유틸리티이다.
manage.py는 자동적으로 각각 장고 프로젝트 안에 생성된다.(프로젝트 시작 하면 자동으로 하나 만들어짐)
manage.py는 django-admin이랑 같으면서 동시에 django_setting_module 환경을 만들어 준다. django-admin 스크립트는 pip를 통해 장고를 설치했으면 시스템 자체에 내장되어 있어 사용가능하다.
만약에 virtualenv(콘다를 제외한 다른 가상환경을 여는 방법)를 사용해서 가상황경을 만들었으면 django-admin은 시스템내에 내장되어 있지 않다. 일반적으로 장고 프로젝트가 작동될때, django-admin보다 manage.py를 이용하는게 더 쉬운 방법이다.
-> 역할: 둘다 디렉토리 만들어줌
manage.py의 특징
1) sys.path에 프로젝트를 추가해준다.
2) 어떤 설정 파일(setting.py)를 쓸지 DJANGO_SETTINGS_MODULE변수에 설정된 값을 이용해 매번 settings.py를 지정하는 불편함을 줄여준다.
✔️ 그럼에도 불구하고 둘다 써야 되는 이유는??
1) manage.py가 생성되려면, 우선 django-admin.py로 프로젝트를 생성할 때 만들어진다. 따라서 후에 manage.py를 이용하려면 우선은 django-admin.py로 첫 시작을 해주어야 하는것이다!!
2) 단일 프로젝트인 경우는 manage.py가 더편하고, 하나의 소스로 여러 환경인경우 setting.py도 여러개로 나누어 쓰는게 일반적이기 때문에 manage.py에 settings.py 경로를 입력해두면 더 편하게 사용이 가능하다. 그러나 별도로 환경변수에 django-setting-module을 설정해서 쓰는 경우에는 django-admin.py를 쓰는게 더 편리할것임..!!! (상황에 따라 다르게 쓰이는것같다)
$ django_admin startproject 프로젝트이름
$ python manage.py startproject 프로젝트이름
장고 프로젝트 구성하는 코드 자동생성 (이 명령어를 통해 데이터베이스 설정, django를 위한 옵션, 어플리케이션을 위한 설정, django인스턴스를 구성하는 수많은 설정들이 생성됨)
앱 생성하기
앱과 프로젝트의 차이?
앱: 웹 어플리케이션, 다양한 프로젝트가 될 수 있다. 예) 웹로그 시스템, 퍼블릭 기록들의 데이터 베이스, 작은 설문조사 앱
장고에서 사용하는 파이썬 패키지.
장고 앱 패키지는 그 안에 model,view,template,url 매핑등을 독자적으로 가지고 있다.
일반적으로 하나의 프로젝트는 하나 이상의 앱으로 구성되어 있다.
=> 약간 프로젝트보다 작은 느낌.. (프로젝트라는 큰 바구니 안에 넣는 공)프로젝트: 환경설정의 모음과 특정한 웹사이트를 위한 앱. 프로젝트는 다양한 앱을 포함한다.
=> 앱을 담고 있는 큰 바구니 같은 느낌...
⭐️ 2. 앱 시작하기
manage.py가 존재하는 프로젝트 파일 내에서 python manage.py startapp 앱이름 으로 앱 시작! 이러면 프로젝트 파일 내부에 앱 딕렉토리가 생긴다.
view 작성
3. views.py 작성(앱 디렉토리 안!!)
models.py에서 필요한 데이터들을 받아서 views.py에서 가공하여 웹페이지에 결과를 만들도록 데이터를 컨트롤 한다.
# 앱 딕렉토리 내부의 views.py
from django.http import HttpResponse
def index(request):
return HttpResponse("Hello, world. You're at the polls index.") # 여기 hello 부분이 url연결을 하면 페이지에 보여짐view는 http Request를 parameter로 받아들이고, HTTpResponse를 리턴한다.
위의 index함수는 http로부터 항상 request를 받아들이고, response를 리턴하게 된다.
views.py의 역할
1) 웹페이지 내용을 갖는 HttpResponse 객체를 리턴
2) Http404 같은 Exception을 리턴
위의 코드에서는 간단한 string만을 returen 했지만, 복잡한 HTML을 처리하기 위해서는 view 템플릿을 사용한다.
4. urls.py (앱 폴더에)
view를 호출하기 위해서 url과 연결이 필요하고 이를 가능하도록 해주는 것이 URLconf
URLconf를 사용하기 위해서 앱 디렉토리 내에 urls.py를 생성한다.
-> views에 있는 데이터들을 앱의 url로 연결해주는 그런 느낌...?
💡 URLconf??
프로젝트가 view파일을 읽어와야 하는데...
이때 url이랑 views함수들을 묶어주는 목차..
프로젝트 디렉토리안에 있는 urls.py에 한번에 url을 연결해주는것보다, 각각의 앱 디렉토리 안에 urls.py파일을 만들어 프로젝트 디렉토리에 있는 urls.py와 매핑해주는 것이 더 효과적이다.
1) 먼저 앱파일 내에 urls.py 연결
# 앱 딕렉토리에 urls.py
from django.urls import path
from . import views
urlpatterns = [
path('', views.index, name='index'),
]💡 path()
필수 parameter: route, view
선택 parameter: kwargs, name
-
route
URL패턴을 가진 문자열.
요청이 처리될때, django는 urlpatterns의 첫번째 패턴부터 시작하여, 일치하는 패턴을 찾을 때 까지 요청된 URL을 각 패턴과 리스트의 순서대로 비교한다.
패턴들은 GET, POST의 매개변수들, 도메인 이름을 검색하지 않는다.
예) https://www.example.com/myapp/이 요청된 경우, URLconf는 오직 myapp/ 부분만 바라본다. https://www.example.com/myapp/?page=3 이런 경우에도 myapp/ 부분만 신경쓴다. -
view
장고에서 일치하는 패턴(route을 통해) 찾으면, 그 경로로 부터 캡쳐된 값을 키워드 인수로 해서 특정한 view 함수를 호출한다.
5. urls.py (프로젝트 파일)
최상위 URLconf에서 앱 폴더에 있는 urls 모듈을 바라보게 설정해야한다.
url은 include함수가 꼭 필요하다.
2) 프로젝트 파일에 있는 메인 urls.py에 앱 url연결.
# 프로젝트 파일의 urls.py
from django.contrib import admin
from django.urls import include, path
urlpatterns = [
path('polls/', include('polls.urls')),
path('admin/', admin.site.urls),
]💡 include가 필요한 이유?
include()함수는 다른 URLconf들을 참조할 수 있도록 도와주는 함수이다.
URL의 시점까지 일치하는 부분을 잘라내고, 남은 문자열 부분 후속처리를 해주기 위해 include를 사용한다. url 패턴을 프로젝트 파일의 urls.py에 포함시킬 때마다 include()를 사용해야 한다. 단, admin.site.urls가 유일한 예외임.
앱에 URLconf(앱/urls.py)가 존재하는 한, 《/polls/》, 또는 《/fun_polls/》, 《/content/polls/》와 같은 경로, 또는 그 어떤 다른 root 경로에 연결하더라도, 앱이 잘 동작할것이다.
=> 여기까지 해보고 url 잘 연결됐는지 또 runserver를 통해서 확인
이때는 연결된 url 확인하는거니깐 주소 뒤에 연결한 앱 url 을 확인해야됨!
