코딩애벌레

곧바로 N:1에 대해서 배워보자. 전에 배웠다시피 게시글과 댓글은 N(댓글):1(게시글) 관계를 갖고 있다. 이미 REST API가 아니더라도 다뤄본 내용의 반복이 대부분이기 때문에 쉽게 따라올 수 있을 것이다. 마찬가지로 comment 도 serializer 사용해주어야 한다. 주의해야 할 부분은 ForiegnKey 부분이니 집중해서 따라가보자..먼저 데이터를 load할 예정이기 때문에 모델을 먼저 작성해주려고 한다. 데이터가 없다면 model을 작성 후에 admin으로 작성해주어도 되고, 매크로를 사용해도 된다.  만들어야 할 HTTP request method 구성을 표로 나타내보고 하나씩 클리어 해보자!URLGETPOSTPUTDELETEcomments/댓글 목록 조회..

지난 시간에 이어서 API 서버를 구축하기 위한 초석을 쌓아보자Django-rest-framework: Django를 기반으로 하는 파이썬 라이브러리: rest_framework에서 제공하는 serializer(직렬화)을 사용하기 위함 Serialization (직렬화): 여러 시스템에서 활용하기 위해 데이터 구조나 객체 상태를 나중에 재구성 할 수 있는 포맷으로 변환하는 과정: 어떠한 언어나 환경에서도 나중에 다시 쉽게 사용할 수 있는 포맷으로 변환하는 과정Postman: html이 사라짐으로써 CRUD를 확인하기 어려워 졌기 때문에 프로그램을 이용하여 데이터 조작을 할 수 있다: API를 구축하고 사용하기 위한 플랫폼: API를 빠르게 만들 수 있는 여러 도구 및 기능을 제..

관계형 데이터 베이스를 배웠으니 django의 백엔드를 통해 저장하고 데이터를 호출하는 법도 배워야 할 차례다. N:1까지는 할만하니 한번 해보자! (django라서 다루기도 쉽다) Many to one relationships (N:1): 한 테이블의 0개 이상의 레코드가 다른 테이블의 레코드 한개와 관련된 관계=> 예를들어 게시글에 댓글을 생각해보자. 한 개의 게시글에는 여러개의 댓글을 달 수 있을 것이다. 이때, Comment는 N, Article은 1이다. CommentArticleidcontentcreated_atupdated_atidtitlecontentcreated_atupdated_at 현재 위처럼 테이블이 작성되어있다고 하면, Article에 댓글이 여러..

이전 시간에는 회원가입을 하지 않고 Admin 계정을 통해 로그인, 로그아웃을 예시로 보여주었다. 모두가 Admin이 될 순 없으니 이제 회원가입을 배워보자! 회원가입 : UserCreationForm() : 회원 가입시 사용자 입력 데이터를 받는 built-in ModelForm 회원가입 페이지까지 확인 되었으니 POST 요청 로직을 마무리하자 저번 시간을 기억해보면 우리는 User 모델을 새롭게 커스텀하려고 가져온 기억이 있을것이다. 그런데 UserCreationForm을 바로 사용할 수 있을까? 회원가입에 사용하는 UserCreationForm이 기존 유저 모델로 인해 작성된 클래스이기 때문에 대체한 유저 모델로 변경을 해주어야 한다. 이후에 배울 UserChangeForm (유저 정보 변경)역시 ..

외워야 할건 점점 늘어난다.. 나 주거~ Authentication (인증) : 사용자가 자신이 누구인지 확인 (=신원 확인) 개발자가 User의 데이터를 직접 다루기 위해서는 custom이 필요하므로 accounts라는 app을 생성하여 직접 정의해야한다. Custom User model로 대체하기 : django가 기본적으로 제공하는 User model이 아닌 직접 작성한 User model을 사용하기 위함 : User class를 대체하는 이유는 django 내부의 내장된 auth 앱의 User class를 사용했는데, 개발자가 직접 수정 불가 : Django는 새 프로젝트를 시작하는 경우 개발자 Custom User Model 설정을 강력히 권장 : 기본 User 모델과 동일하게 작동 하면서도 필..

저번 시간에 model을 다루게 되면서 DB를 맛보게 되었다. 오늘은 데이터를 가공하는 과정을 거쳐볼 것이다. admin을 통해 데이터를 생성할 수 있지만, 나중에 배우게 될 데이터 간의 관계와 호출에서 사용이 되기 때문에 기초를 잘 다룰줄 알아야 응용이 된다. ORM (Object-Relational-Mapping) : 객체 지향 프로그래밍 언어를 사용하여 호환되지 않는 유형의 시스템 간에 데이터를 변환하는 기술 : 데이터베이스 쿼리를 추상화하여 Django 개발자가 데이터 베이스와 직접 상호작용 하지 않아도 가능하도록 만듦 : 데이터베이스와의 결합도를 낮추고 개발자가 직관적이고 생산적으로 개발할 수 있도록 도움 QuerySet API : Django에 내장된 ORM으로 데이터를 검색, 필터링, 정렬 ..

오늘은 드디어 모델을 만들어 볼것이다. 이는 실질적으로 DB를 관리할 수 있는 첫 걸음이다. 지금 이해해야 나중에 form을 다루면서 외우는 식이 아닌 이해하는 식으로 django를 풀어나갈 수 있다. 진짜 머리아픈 부분의 시작이니 잘 따라가보자 Model : DB의 테이블을 정의하고 데이터를 조작할 수 있는 기능들을 제공 (DB를 직접 다루는 것은 SQLite로 진행 예정) => 어떤 데이터를 저장할지 테이블 구조를 설계하는 '청사진(Blueprint)' 다. 게시글을 예로들면 제목과 내용을 데이터로 저장하려면 title과 content를 작성한다고 가정하자. 먼저 class 선언을 하여 내가 사용할 model을 정의한다 . 모델명 - 모델에 들어갈 필드(데이터 테이블)명 - 해당하는 데이터 타입 - ..

지금까지 어느정도 윤곽은 잡아놨고, url의 사용방법 변경을 변경하게 되면서 앞의 내용을 왜 배웠나 싶지만.. 모든건 이유가 있다고 생각한다. 어떻게 발전해왔고 어떤 의미를 뜻하는지 천천히 쫓아간다면 오히려 이해가 되기 때문이다. 그러나 유독 django는 배우면 '하지만!! 더 좋은게 있죠?' 의 느낌은 떨쳐내긴 어렵다.. 그래도 하나씩 알아가는건 재밌는 것 같다. Django URLs 계속 다뤄온 url을 왜 다시 다루게 되었을까? urls의 정의를 떠올려보자. URL dispatcher (운항 관리자, 분배기)로 URL 패턴을 정의하고 패턴이 일치하는 요청을 처리할 view 함수를 연결(매핑) 하는 것. 그림으로 깔끔하게 설명할 수 있다. 우리는 project dir 내부에서 urls 파일에 패턴을..

오늘은 지금까지 배웠던 부분이 나오며, 심화되어서 정리하는 부분이라고 생각하면 좋다. 이전 시간에 URL을 form 내부의 action을 수정하여 직접 만든 페이지에서 Google의 홈페이지로 검색하게 만드는 것을 했다. 이번에는 입력한 Text를 내가 만든 페이지에 띄우는 것을 할 것이다. 사용자 입력 데이터를 받아 출력하기 데이터를 던져주는 Throw, 데이터를 받아 출력하는 Catch가 필요하다. 캐치볼 게임을 한다고 생각하면 편할 것 같다. 그렇다면 필요한 요소는 뭘까? View 함수에 필요한 함수는 몇개며, html 페이지는 몇개인지. 데이터를 받는 함수, 데이터를 출력하는 함수 / 데이터를 받는 페이지, 데이터를 출력하는 페이지로 총 두 세트가 필요한 것을 이젠 알아야 한다! 시작은 어떻게? ..

저번 시간까지 페이지 구성까지 만들어 봤다. 사실 한 페이지만 만드는 것이라고 생각하면 html 파일에 때려박으면 되는데, 그렇게되면 찍힌 사진을 보고있는 것과 같다. 우리는 동영상을 만들어야 하니까! 오늘은 페이지를 더 효율적으로 관리할 수 있는 방법들, 즉 '상속'에 대해 배워보자. 게시글이 많지는 않지만 대부분 홈페이지들은 고정적으로 출력되는 부분이 많이 있을 것이다. 그렇다면 해당 페이지 요청이 들어왔을 때 html을 처음부터 다시 다불러올까? 한번 생각해보자. 위의 파일들이 문제가 될까? 물론 아니다. 출력되는데 문제는 전혀 없다. 하지만 언젠간 페이지를 유지보수한다면 어떨까? 그러면 모든 HTML 파일을 찾아서 달라진 부분을 일일이 수정해줘야한다. 예시는 3개라서 3번만 고치면 되지만 100번..