장고 Template extends include 구문, render
HTML (Hyper Text Markup Language)
: 문서간 이동이 가능한 text
장고 템플릿에서 자주 쓰이는 구문
-
extends: 템플릿처럼 구역을 나눠서 html 파일을 미리 만들어두고 이걸 가져와서 이것을 바탕으로 이 안에 있는 블럭들을 내용으로 채워나간다는 형식으로 extends 구문 사용 (바탕을 깔아주는 느낌)
-
include: 만들고 있는 html 파일이 있다고 하면 거기다가 조그마한 조각 같은 것을 가져와서 템플릿 안에 넣는 형식으로 include 구문 사용 (블럭을 가져와서 붙이는 느낌)
이 둘은 html을 가져온다는 느낌은 비슷, 사용용도의 차이
Static 설정 및 CSS 파일 분리
: css파일 - 디자인 파일만 따로 분리해놓은 것
( html 파일에 style로 속성값을 따로 정해줬는데, html 뼈대만 남겨두고 style과 같은 디자인적 요소는 CSS 파일로 빼서 따로 관리)
분리하기 전에 static 설정해야함
static
: '정적인' -> CSS, JavaScript, Font와 같이 자주 변경되지 않는 파일/앱/프로젝트 별로 따로 관리
설정 ) settings.py에서 STATIC_URL 밑에 STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles') 루트 설정 (collectstatic이라는 명령어는 프로젝트 안에 있는 모든 static파일들을 한 군데로 모아주는 명령어인데, 이를 통해 어디로 파일을 모을 것인지 알려주는 것이 static root)
+) os는 라이브러리, (os에서 제공하는 함수, 모듈들)
path는 경로 관련한 모듈
그 중에서도 join이라는 fuction
BASE_DIR는 (파이참은 Ctrl + B누르면 선언된 내용으로 건너뜀) 위의 위의(parent.parent) 폴더를 베이스 디렉토리로 하겠다는 것
CSS 핵심
DISPLAY Attribute
: HTML 태그들마다 디스플레이 속성 존재, 디스플레이 속성들은 우리가 보는 화면을 어떻게 구성하는지/ 어떤 부분을 어떤 알고리즘(원리)로 구성하게 되는지 알아야 함
- Block
- Inline
- Inline-block
- None
Block
: 모든 태그에는 부모가 존재, 그 부모의 최대한의 너비를 모두 가져가면서 블록 형태를 가지는 것
높이는 따로 설정하지 않는 이상 기본적으로 설정된 값 혹은 내용물에 맞춰서 그 크기가 결정 
Inline
: 글씨의 높이만큼 한 줄 내에 일정 부분만 가져감 (Block은 밑으로 계속 쌓이겠지만 Inline 경우 오른쪽으로 한줄로 block 쌓임) 
Inline-block
: block인데도 불구하고 인라인처럼 오른쪽으로 쌓이는것으로 구성된 블록
None
: 말그대로 없음 아예 존재 x -> html 태그는 있으나 브라우저 시각화되는 과정에서는 아무것도 없음
+) 시각화 속성(Hidden)과 차이 
None이면 display가 아예 없어진 후에 child2가 앞으로 당겨옴
Hidden 속성이면 보이지만 않을뿐 존재함
SIZE Attribute
: 사이트를 반응형으로 만들어야함 (html 태그들이 데스크탑 사이즈에서도 볼 수 있고 모바일 사이즈에서도 볼 수 있으므로 크기가 어떻게 변하는지에 대한 통제력 필요)
사이즈 지정할 수 있는 단위 4가지
- px
- em
- 👑 rem
- %
px
child의 가로세로 너비가 100px이라고 하면 부모가 커지든 작아지든 어떻게 되는 상관없이 그냥 100px 고정 (parent의 폰트 사이즈 변화도 상관 x)
em
부모가 변하면 변하는대로 child가 따라감 (부모가 1.5x 커지면 150px, 0.5x 작아지면 50px)
+) 여러가지 부모가 있는 경우 문제 발생
부모에서 부모에서 받은 모든 것들을 합해서 모두 곱한 상태로 변화
rem
root HTML에 기본적으로 적용돼있는 폰트 사이즈 존재 (브라우저마다 다를 수 있음) root HTML의 값을 따라감 => 바로 위에 있는 부모의 사이즈에는 영향 받지 않으나 root HTML이 변한만큼 사이즈 따라감
%
바로 위의 부모 크기만 받음
정리 ) 
Model, DB 연동
Model
: 장고 database 연동시켜주는 작업
+) 명령어
python manage.py makemigrations ) models.py에 쓰는 내용을 db와 연동시킬 파이썬 파일로 만들어주는 작업
python manage.py migrate ) 만든 파이썬 파일을 장고와 연동시켜주는 명령어
/* db에 대한 정보를 settings파일에서 볼 수 있음
DATABASE에 보면 'NAME': BASE_DIR / 'db.sqlite3' 있음 -> db.sqlite3라는 이름으로 BASE_DIR에 있다는 뜻
HTTP 프로토콜 GET, POST
HTTP Protocol
: 컴퓨터와 컴퓨터끼리 통신하는 과정에서 사용되는 규약
중요하게 알아야 할 두가지 메소드
- GET
- POST
서버와 유저가 있으면 요청을 보내고 응답이 오는 형식으로 모든 서버가 동작함
여기서 get/post를 사용해서 보내주는데 get/post에서 서버에서 뭘 보내줘야하는지에 대한 추가적인 정보를 넣어주는 방식이라고 생각하면 됨
ex)https://onion.haus/만드려고 하는 이 사이트의 주소로 요청을 보낸다고 하면 get 방식의 경우, 조회를 하기 위해 요청을 많이 보냄 (새로 만드는 것보단 데이터 적게 필요)
=> get은 주소 안에다가 추가적은 파라미터 넣어서 보냄https://onion.haus/?param1=value1(? : 파라미터 시작한다는 뜻 param1에 value1으로 매칭을 시켜서 서버로 보냄, 서버 측에서는 그 파라미터를 가지고 추가적인 작업해서 응답 보내줌)
=> post는 정보를 만들거나 수정할때 사용. 같은 주소를 보낸다고 하더라도 파라미터를 붙이는 게 아니라 추가적으로 body라는 응답 외부에 있는 몸통에다가 데이터 넣어서 보냄)
Account App
form에서 HelloWorld 요청을 보낼 때 아무나 보낼 수 있음 -> 인증시스템 (최소한의 보안)
Account
- Sign up
< login - View info (계정 정보)
- Change info (정보 변경)
- Quit (탈퇴)
+) 장고 기능 - crud에 생산성 탁월
why) 각각의 View를 따로 제공 (네 가지 작업들을 쉽게 할 수 있는 클래스 제공)
-
C - Create (Create View)
-
R - Read (Read view)
-
U - Update (Update view)
-
D - Delete (Delete view)
=> Class Based View 제공 <-> Function Based View (Hello World와 같이 함수 기반의 뷰 모델)- Function Based View
길어지면 가독성 떨어지고 복잡해짐 - Class Based View
CreateView가 장고에서 기본적으로 제공해주는 클래스 (이걸 상속받아서 새로운 view를 만들거고 거기에 들어가는 몇개의 파라미터만 지정해주면 나머지는 장고가 알아서 해줌)
=> CBV 사용하면 생산성, 가독성 높아지고 복잡도와 쓰는 시간 줄어듦
거의 대부분이 이 사이클 안에 적용가능
- Function Based View
