이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 배포

✍ heroku cloud service 를 이용하여 로컬환경에서만 확인하던 사이트를 url 생성 후 배포시켜 어느 환경에서든 확인할 수 있게 세팅하려고 한다.

heroku 는 서버를 가지고 있는것 처럼 웹의 공간을 대행해주는 cloud platform 이라고 생각하면 될 것 같다. 작업 방식은 git 을 통해 push / pull 을 하며, 소스를 서버에 반영할 수 가 있다.

해당 과정을 진행하며 heroku 회원가입 등 기초 작업들은 따로 포스팅 하지 않고, 실질적인 terminal 창에서 url 생성 및 git 배포 과정만 남겨보겠다.

1. heroku cli download = mac version에서는 terminal 창에서 direct로 입력하여 download를 진행하면 되고, windows 환경에서는 installer로 download가 가능하다.

---

2. Procfile 생성 = 일종의 설정 .ini file이다. 배포 시 필요한 코드인 것 같다.

---

3. heroku login (이하 단계는 terminal 이용) = 배포를 진행하기에 앞서서, heroku login 명령어를 입력 시 로그인 page로 이동하고, 본인의 계정을 입력 후 로그인을 진행하면 다음 단계로 넘어간다.

---

4. app 생성 = 접속할 주소를 제공해주는 app을 생성한다. heroku create 명령어 뒤에는 생성하고자 하는 name 을 대입시키면, https 로 시작하는 url이 생성된다. 그 후, 주소값 대입 시 접속은 되나, 별다른 내용이 없을 것이다. 보여주고자 하는 내용을 배포 시켜야 보이게 된다.

---

5. local -> heroku로 file 전달 (add) = 서버에 올릴 file 목록들을 add 시킨다.

---

6. commit = 배포 시킬 file들을 add 시킨 후, 서버에 commit 시켜준다. (commit 뒤의 내용들은 commit message를 뜻한다.)

---

7. push = commit 된 file들을 push 시켜서 실질적으로 서버에 반영시킨다. 하지만, 하단에 repository error 가 보인다. 원인은, remote 주소가 변경되지 않아 발생한 error 였다.

이같은 경우에는 생성된 app name을 연결시켜주면 된다. 😎 = *즉, heroku git remote -a를 나의 app으로 변경시켜 달라는 의미이다. *정상적으로 remote 된 것을 확인할 수 있다.

---

= 정상적으로 변경 후, push를 진행할 시,

---

= done ! 배포가 완료되고 flask 실행까지 진행된다.

---

9. 배포 확인 = 로컬에서 작업한 화면을 생성한 app url을 입력 후 페이지 확인 시, 정상적으로 배포 된 것을 확인할 수 있다!

---

10. heroku 30 minute 현재 간단한 onlinestore 테스트를 위해, heroku 라는 cloud platform 을 이용하여 배포하였는데, heroku의 특징이 30분 내에 접속하지 않을 시 잠자기 모드로 변환된다고 하였다.

사실, 테스트가 아닌 실제로 onlinestore를 운영할 때는 정식적으로 값을 지불하고 서버를 구축하여 사용 할 것인데, 테스트용으로 확인하기 위해서는 heroku cloud 가 필요했다.

그래서 알아본 결과, 자신의 도메인을 setInterval을 활용하여 호출시켜주는 방법도 있었고, url만 입력하면, 스스로 호출을 해주는 솔루션을 가진 홈페이지도 존재하였다.

일단 등록을 시켜 둔 상태고, 이렇게 결과물이 완료되었다.

앞으로의 계획은 수많은 것들이 구상되어 있는데, 사업 아이템으로 점차 확장시킬 항목들이라 추후에 버전업이 되고 상용화 될 때 포스팅하겠다.

구상한 계획들을 준비하는 아주 큰 첫걸음이 된 작업물이었다고 생각한다!! 😎😎

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 구매한 주문 목록

✍ 결제를 성공할 시, 각 상품의 status 값이 "complete" 값으로 변환된다. 하지만, 현재 주문 목록에는 주문을 실패한 항목들까지 노출이 되고 있다. 즉, status가 complete(주문완료) 된 항목만 뿌려지게 해보겠다.

1. 주문 목록 로직 이해 = find가 정의된 부분을 찾아가보면(models > order.py) 주문목록의 document 모두를 가져오게 처리되어 있다. 그러므로, 현재 수정할 방법은 status값이 complete 된 항목들만 가져올 것이다.

---

2. 상태값 생성 (controllers > order.py) = status가 complete인 항목을 match 변수에 대입시키고, document 전체에서 가져왔던 주문목록을 match값만 가져올 수 있도록 find 내부에 대입시켜준다.

---

3. 받아올 값 생성 (models > order.py) = match 가 없는 경우에는 {} 내부 값을 사용한다고 정의 시켜주고, match 값을 대입시켜준다. match 값은 status 가 complete값이므로 주문이 성공한 목록만 그대로 가져올 것이다.

---

4. 결과화면 = 상태값이 complete인 주문 목록들만 뿌려지게 된다. (테스트를 조금 진행해서 해당 항목들이 구분이 잘 가지 않겠지만 .. ^^;; db를 통해서 확인해보면 complete 값이 맞다.)

이렇게 주문 파트가 마무리 되었다 ! 🎉

이제 남은 부분은 현재 로컬에서 작업한 파일들을 주소값을 입력 했을 때, 어느 환경에서나 확인할 수 있도록 하려고 한다.

다음 시간에는 배포로 마무리 해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. payment complete 성공

✍ payment 결제가 완료된다면, 완료된 정보를 ajax 내부 done data에 전달하는 작업을 해 보겠다.

이번 작업을 하면서 구문에 익숙하지가 않다보니, 정말 별것도 아닌 디버깅 문제로 새벽까지 재미나게(?) 해결해본 이번 챕터이다 😵‍💫

확실히 겪은 문제를 토대로 작업내용을 공유해 보고자 한다.

우선, controllers > payment file에서 성공하게 되면 order id와 message를 전달해 주게 된다.

그 전달받은 값을 ajax done 값에 활용할 것이다.

1. 가맹점 서버 결제 API 성공시 로직 = 성공 시 message를 success로 전달했으므로 ( return jsonify({'order_id': merchant_uid, 'message': 'success'} = 전달을 받기 위해 jsonify 구문 사용 ) ), data의 message가 success일 경우 구문을 하나 생성한다.

---

= 성공한다면, data에서 전달받은 id를 정의하고, success 주소값을 생성하여 해당 url로 요청한다는 구문이다.

🧨🧨여기서 주소값을 넘길 때 ' 가 아닌, ` 로 넘겨주어야 한다. 이 백틱을 잡아내기위해 정상적인 코드를 몇번이나 엎었다 😂😂 하지만 확실히 알고 두번다시 실수하지 않을 것 같아 뜻깊은 경험이었다고 생각한다 😎 🧨🧨

---

2. 결제 실패 시 로직 = 단순하다. alert 창을 띄우고 상품 list(main) page로 이동 시켜주면 된다. 하지만, data alert를 사용하기 위해서는 몇가지 세팅이 필요하다. = (controllers > payment.py) message로 전달을 하고, alert창에서 data의 message로 받아준다면 해당 내용이 정상적으로 보여 질 것이다.

---

3. SUCCESS API 생성 ( controllers > payment.py ) = ajax 내부에서도 order_id값을 parameter로 받아왔기 때문에 해당 구문에서도 order_id를 요청해 받아오고, 그 요청한 고유 id값을 넘겨주었다.

---

4. payment_complete.html 내부에서 값 출력 = 해당 주문 내역을 상세하게 확인하기 위해 주문 완료 메시지 및 order_id값만 넘겨주었다.

---

5. 주문 및 결제 테스트 = 하지만 결제 시 "비정상적인 결제입니다." 라는 alert가 출력 될 것이다. 실패되어 fail 구문으로 튕겼다는 뜻이다. = 데이터가 없거나 amount와 상품 가격이 일치하지 않은 경우에 else 구문이 작동되었을 것이다.

---

이유는 product의 price는 string값으로 존재하는데, payment_data의 amount는 int로 되어있다. type이 달라서 같지 않은 부분이 생긴 것이다.

---

방법은, product를 저장할 때 int값으로 변경해주고

---

update 를 해줄때도 price값을 int값으로 변경 시켜준다.

---

이제 별다른 변수가 없다면, 주문 및 결제가 정상적으로 완료 될 것이다. 테스트를 통해 확인 해 보겠다. = 상품정보, 주문정보, 결제정보 등이 db에 담긴 내역이며, 실제 주문 후 결제까지 거쳐 금액이 빠져나가는 것도 정상적으로 작동되는 것을 확인하였다!

이렇게 주문 후 결제까지 구현을 해 보았다.

온라인 스토어 작업을 하던 중 개강시기가 겹쳐 끝까지 만들 수 있을까 걱정했는데, 수업 중간마다 여유시간이 생겨 차질없이 마무리 할 수 있을 것 같다 😎

다음시간에는 구매 목록을 마무리 해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 결제 성공 시 flask 처리 API

✍ 결제가 완료된다면, 완료의 단면적인 부분이 아닌 여러 절차를 생각해 보아야 한다. 우선, 간단한 로직을 생각해보면 (1) 결제가 완료되고 (2) 결제가 실제로 정상적으로 완료되었는지 확인하는 절차가 필요하며 (3) 결제에 대한 정보를 저장하고 (4) 주문 document status를 완료 상태로 업데이트 시키는 API가 필요하다.

각 순서별로 코드를 짜서 API를 추가시켜 보겠다.

1. route 및 함수 생성 = complete 주소로 받고, 함수를 생성했으며 결제 성공 또한 로그인이 되어있다는 전제 하에 진행되므로 로그인 여부를 체크하는 코드를 추가시켰다.

---

2. request data 및 결제관련 id값 받아오기 = request_data의 경우에는 payment.html file 내부의 ajax값 안의 data를 뜻하고, 그 data 안에는 imp_uid및 merchant_uid의(결제에 필요한 data값들)을 담아둔 것이다. 이 값들을 받아와서 저장해야 하므로 가져온다.

🔖 payment.html 참고

---

3. 결제가 정상적으로 완료되었는지 확인 = 확인을 위해서는 iamport API를 이용해서 확인해야 하는데, API site에서는 node를 활용하여 작업을 해두었다.😵‍💫 그러므로, node 코드를 확인하여 python code 로 알맞게 작업을 해 보겠다.

(1) 우선, API 상의 url을 사용한다. (2) data key(iamport 관리자 홈페이지 참조) (3) headers 정의 headers = {'Content-Type': 'application/json'} = application/json type으로 보내겠다고 선언

(4) 요청 보내기 = 너무 정신이 없다. 하지만 이해를 위해서는 어쩔 수 없었다(?) 값을 변수에 담고, 그 변수가 어디에 저장되고 어디에 뿌려지는지 정확히 이해하고 넘어가야 혼동을 줄일 수 있다.

우선 url, headers, data 값을 res 변수에 담았다. ** = request 및 json이 import 되어 있지 않으므로, 사용을 위해서 import 시켜준다.**

res = res.json() 그 후, response를 json으로 변환하여 다시 res 변수에 담아준다. = API를 살펴보면, data를 감싼 getToken을 data.response의 access token 으로 받아오는 것을 확인할 수 있다. 이 코드를 동일하게 작업하되, python으로 변경하면 = response로 접근하여 access_token을 가져온다.

= 결제정보를 조회할 수 있는 API를 사용하기 위해서 token을 발급받았고, 그 발급받은 token을 이용하여 조회할 수 있게끔 작업해 준 코드이다.

물론 API 상에서 해당 코드가 node로 작업되어 있고, python 형식에 맞게 변환시켜 주었다.

🔖 참고)

---

= 그 후, request를 get방식으로 실행하여 json으로 불러온다. ( url 및 headers) 가져온 후 response key값으로 payment_data를 꺼내온다.

---

= payment data와 payment_data 내부의 실제 결제한 값(amount) 와 상품가격(product > price) 가 같다면 -> 정상적으로 결제가 완료된 것이다. (status 값은 success로 세팅해준다.)

= 그 가격은 order에서 찾아준다. order 가 없다면 return 값을 띄워준다.

---

= 결제에 대한 정보를 저장하기 위해 insert_one을 이용하여 주문 정보와, 결제정보와, 상태를 저장해 준다. payment class는 현재 존재하지 않으므로, 생성해 주어야 한다.

---

(5) models > payment.py 생성 = 주문정보, 결제정보, 상태를 받아온다.

---

(6) payment 생성 후 import

---

(7) 비 정상적인 결제일 경우 = 이렇게 결제에 대한 정보를 저장하는 단계를 거친 후, 주문 document status 상태로 update 시켜주어야 한다.

---

(8) 주문 document status 상태로 update = status 값은 complete로 지정해주고, status 값과 merchant_uid 값을 update 시켜준다. 다 완료가 되었다면, order_id는 merchant_uid 값으로, message는 success 값으로 return 시킨다.

---

(9) order update_one ( models > order.py ) = 어떤 주문정보를 update 할 것인지 확인

payment.html ajax 내부에서 결제가 성공될 경우 요청 시 생성한 API로 들어와서 결제 확인 및 결제 정보를 저장하고 주문상태를 update 해주게끔 코드를 작성했다 🎉

기존 API를 활용하여 python 형식에 맞게 작업하다보니 시간도 배로 걸리고 구문이 아직 익숙치 않다.

이번 작업이 마무리되면, 여러 type의 쇼핑몰도 생성하고 간단하지만 다른 조건부들을 주어 선택지를 다양하게 생성해 보려는 계획을 가지고 있다!

다음 시간에는 API가 성공이 되면 정보를 ajax 내부 done data에 전달하는 작업을 해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 결제 요청

✍ 지난 시간에는 form을 작성하고, 작성한 form의 고유 id값이 넘어오는 것 까지 확인 해 보았다.

이번시간에는, iamport를 활용하여 pg사를 연동시켜 실제 금액이 빠져나가고, 취소했을 때 환불처리 되는 것 까지 구현해 보려고 한다.

기존에 정말 해보고 싶었던 작업이고, 까다로운 요소들도 많지만 차근차근 작업 해 보겠다!

1. iamport script import = library 사용을 위해서는 지원하고 있는 script file을 import 시킨 후 작업을 시작한다. {SDK-최신버전} 부분은 현재 최신버전을 문서에서 서칭하여 표기해 주면 된다. = iamport.payment-1.1.8.js

---

2. 결제 준비 코드 작성 = 가맹점 식별코드는 iamport 관리자콘솔 -> 상점/계정관리 -> 내 식별코드 Appkeys 에서 확인가능하다. = 확인한 식별코드를 Imp.Init 뒤 식별 코드에 붙여넣어준다.

---

3. 결제 요청 코드 작성 = 해당 코드를 입력 시 정보가 기입되어 있는 pg사 결제창(이전 작업에서 다날 로 테스트pg사를 추가해 둠)이 나타날 것이고, 실질적으로 결제가 가능할 것이다. = 우선 작업 후 결과 코드인데, 하나씩 순차적으로 설명해 보겠다.

DOM이 로드 된 후, requestPay 함수를 호출시켜 정상적으로 pg사 popup을 띄우면 성공이다. 그렇게 되야한다...

예상대로라면 문제없이 PG사 결제창이 popup으로 뜰텐데 결제 실패시 로직이 떠버렸다. 즉, reqeustPay 함수가 정상적으로 실행되지 않고, else로 튕겼다는 것이다 😂

우선 로직을 따라 차근차근 하나씩 읽어보았다.

구문상 문제는 없어보였고, 함수 안의 내용도 하나씩 살펴보았다. 구문을 몇번이고 다시 읽어보고, 서칭을 해보아도 답이 없었는데, 하나 이상한 점이 있었다.

나는 pg사를 다날로 세팅했는데, 현재 코드 상으로는 inis가 입력되있다(?) = 이 구문을 danal_tpay로 입력하니 결제창이 잘 나온다 하하하 ^___^

별거 아닐거 같단 느낌이 들었고 예상은 했는데 이 문제로 40분이나 배움의 시간이 확보되었다 ..😵‍💫😵‍💫

---

4. 실 데이터 추가 = 실제로 결제가 진행되는 pg 사 결제창이 나타났다. 신한pay로 직접 결제 후 나타나는 화면들을 구현해 보겠다.

5. 실결제테스트 = 신한pay로 결제 후 정상적으로 결제가 된다면 결제를 기다리는 popup 창이 하나 나타난다. 여기서 결제를 클릭하게 된다면 실제 돈이 빠지게 되며, 정상적으로 구매가 완료된다.
   결제내역 확인 부분에서는 수단, 개월수, 구매자 및 이메일, 상품명, 상품금액, 결제금액 등이 db의 실제 data가 정상적으로 출력되고 있다. = 결제 버튼 클릭 시 console에 찍힌 결제 성공 text가 출력된다. 아직 결제 후 이후 과정을 작업하지 않았기에 console 만 뜨는것이 정상이다. = 그 후, 상품의 금액이 정상적으로 출금되는 것이 확인된다.

6. 결제 승인 내역 확인 = 여러번 테스트를 하였는데, 미결제 내역 및 구매한 내역이 정상적으로 출력된다.
   🔖 만약, 구매가 완료된 상품을 판매자의 사정으로 환불처리를 하거나, 구매자의 사정으로 구매를 취소 할 수도 있다. 그러므로 현재 관리자 콘솔에서 상품을 취소할 시 정상적으로 환불처리가 되는 것도 확인하였다.

7. 결제 성공 시 결제정보전달 = 결제 요청이 끝난 후 완료가 되었을 때 flask에 전달해 주어야 한다.
   = payment/complete 주소 및 post방식으로 전달해 주었다.

실질적으로 구매한 금액이 정상적으로 출금되고, 취소한 상품에 대해서 즉시 환불처리 되는 로직을 구현해 보았다!

순탄하게 작업이 진행되면 좋겠지만, 오류가 생기고 그 오류를 해결하는 과정에 있어서 더 많은 것들을 찾게 되고 부가적으로 득이 되는 것들이 더 많은 것 같았다. 😎🎉

다음 시간에는 결제 성공 API를 작성해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 구매 프로세스

✍ 우선, 상품을 구매 후 결제하는 과정에 있어서 해당 로직을 생각나는대로 적어보겠다.

결제 버튼 클릭 시 결제 요청 페이지가 나오고 -> 결제 창이 오픈 되며(통상적으로 popup이 될 것 같다) -> 구매자가 결제를 완료할 시 -> 결제 확인 화면이 나타나고 -> 주문이 완료되며 (결제 금액 및 주소 확인) -> 상품을 구매 완료 시킨다.

결제를 구현하는데에 있어서는 iamport를 사용할 것이며,

iamport -> 결제 요청 시 결제 창을 열어주고, 사용자 -> 결제를 하게 되면 결제 후 결제확인 단계에서도 iamport API를 통해 결제가 제대로 된 지 확인 할 것이며,

주문이 완료 되었다면, 주문 상태를 update 시켜주면 정상적으로 결제가 포함된 주문이 완료 될 것이다.

이전 시간에는 주문하기 버튼을 클릭 시 무조건적으로 완료 페이지로 넘겼다면, 이번 시간에는 결제 요청 페이지를 생성 후 고유 id값을 넘겨 받는 것 까지 해보겠다.

1. 아임포트 회원가입

---

2. PG사(다날 이용) 테스트모드 저장

---

3. controllers > payment.py 생성 = 우선, 파일만 생성 한 후 blueprint에서 payment 값으로 등록시켜준다(payment/filename)

---

4. 결제 요청 API 생성 = payment를 이용하여 /request 값으로 route 시켜 돌려주고, request_payment 함수를 하나 생성한다. = 결제 요청을 하기 위해서는 로그인이 당연시 되어야 하는 부분이므로, 로그인을 check 하는 코드를 기존에 사용했던 것과 동일하게 작성해준다. = 어떤 주문에 대한 결제인지에 대해 알고 있어야 하므로, order에 대한 정보가 필요하다.

find_one을 이용하여 order의 id를 가져오는데, 어디서 받아오는지에 대해 명시되어 있어야 한다.

그러므로, order_id 변수를 생성 후, .argument.get 으로 값을 받아온다. 즉, 이 값은 request api 로 들어올 때 ? 뒤의 값을 가져오는 것이다. 받아온 값은 payment.html 로 이동시켜준다.

---

5. app.py -> blueprint 등록

---

6. payment.html file 생성 = 현재 넘겨온 값을 확인하기 위해 order 값만 받아온 상태이다.

다른 작업들을 거친 후, 마지막에 주문 폼을 작성한 후 값을 전송한다면, 해당 폼의 내용들이 출력 될 것이다. (마지막에 확인 해 보겠다.)

---

7. request_payment api를 호출시킬 부분 생성 = 주문하기 버튼을 클릭 시 해당 주소값으로 post값이 전송되는데, 값이 전송될 때 request_payment API 가 호출이 되어야 한다. = 그러므로, controllers > product.py file 에서 redirect 값을 이용하여 호출 시켜 주고, order_id parameter를 이용한다.

🔖 api 뒤 order_id는 insert_one, 즉 새로 생성 시 order_id를 가져와야 하므로, order_id 변수를 생성하여 insert_one 생성 구문을 감싼다.

---

8. models > order.py file 에서 return 처리 = 생성되었을 때, 고유번호를 return 시켜준다.

즉, 새로 생성하는 요소들을 new_order_doc 변수로 감싸고, 그 감싼 값을 return 시켜준 후, product.py에 order_id를 받아서 redirect 시 order_id를 parameter 로 넘겨준다.

---

9. payment import(controllers > product.py)

---

10. 주문 폼 작성 및 넘겨준 값 확인 = 값을 담아서, post값으로 전송 시 해당 값들이 출력되어야 한다. (현재 payment.html file에서 order 값 출력되도록 작업 {{order}} )

= form 내부에 작성한 값들과 고유 id값이 정상적으로 넘어오는 것을 확인할 수 있다.

작업을 하다 보니, 실제로 사용하기 위해서는 PG사 심사 및 여러까지 까다로운 절차들이 많을 것으로 예상된다 😂

하지만, 실질적으로 직접 사용할 사업자를 초빙(?) 하여 심사 및 결제시스템을 도입하여 사용해 본다면 점차적으로 type 이 다른 여러 쇼핑몰을 만들어 낼 수 있겠다는 판단이 들었다. (곧 개강이라 시간이 문제다 시간이 ㅠㅠ)

아무쪼록 목표에 점점 가까워지고있다 !!

다음 시간에는 결제요청을 구현해 보도록 하겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 구매결과 조회

✍ 사용자가 구매를 완료하였다면, 구매를 완료한 상품의 목록 및 상세페이지가 필요할 것이다.

우선, 주문완료 상품의 목록부터 확인이 가능하도록 구성해 보겠다.

1. 주문완료 controller 생성

📍 blueprint 생성 = order 주소를 가진 blueprint controller 생성

---

📍 controllers > order.py 생성 = blueprint order 추가 및 order 사용

---

📍 app.py > order blueprint 등록 = order import 및 prefix는 order는 이용

---

2. 구매 완료한 상품 목록 API 생성(controllers > order.py) = 구매완료된 리스트이므로 당연히 로그인 된 상태에서 확인이 가능하므로 check_login을 사용하여 로그인 유무 체크를 먼저 진행한다.

그 후, 주문목록을 가져와야 하는데, find 함수를 사용하여 가져오도록 하겠다

---

3. find 함수 생성(models > order.py) = db의 orders에 있는 모든 document를 가져와서 orders 변수에 저장시켜주고 orders를 return 시켜준다.

---

4. orders 사용 = import 및 models > order.py에서 return 받아온 orders 사용한다. 이 정보를 가지고 html에서 보여주어야 한다.(orders.html 생성 및 orders 정보 html file에 던져줌)

---

5. orders.html file 생성(구매한 주문 목록) = 여기서 유의할 부분은 render_template 생성 후 product가 아닌 orders를 넘겨주었기 때문에,

{% for order in orders %} = 넘겨준 orders 값을 order로 받아서 order의 product를 타고 해당 값을 가져온다.

order > product > ___

---

= 주문목록 페이지 결과화면

---

우선 주문한 상품의 목록 페이지는 끝이났다. 다음으로는 주문한 상품의 상세페이지를 확인해보겠다.

1. 상세 페이지 API 생성 = 주문 목록과 유사하나, 상품 상세 페이지는 어떤 order인지가 필요하므로 order_id 고유값을 가져온다.

상세페이지도 동일하게 로그인이 필요하여 check_login으로 체크했으며, order_id 하나만 찾으면 되므로, find_one으로 order_id를 주소값에서 받아서 넘겨줄 것이다.

---

2. 넘긴 order_id를 find_one으로 찾기(models > order.py) = 넘어온 order_id 값을 _id 주소로(db안의 _id를 찾는것) document를 찾는다. 그 후 order를 return 시킨다.

🔖 ObjectId를 받아온 이유는 db안의 id값이 ObjectID값으로 설정되어 있어 맞춰주었다.

---

3. order.html file 생성(주문완료 상세 페이지) = 유의할 점은 주문목록과 동일하게 order의 product 안에 가져올 data들이 있다는 점이다.

---

4. 주문목록 페이지에서 상세페이지 이동 링크 = orders의 order_id 고유값으로 던져준다(이동) -> order controllers 안의 상세 페이지로 이동되는 부분이 작동된다.

---

5. 배송지 / 주문자정보 추가 = order 안의 각자 해당되는 data값을 가져온다.

이렇게 주문완료된 목록 및 상세페이지를 구현해 보았다. 직접 사용자 및 상품의 data를 넘기고, 그 넘겨진 값을 받아서 db에서 확인 후 직접 뿌려지는 과정까지 구현해 보니 front와는 또 다른 재미가 있는 것 같다. 😎

다음 시간에는 드디어 결제 모듈을 연동시켜 보겠다!!!!🎉

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품구매 프로세스

✍ 상품 구매에 대한 전반적인 순서를 그려보고 이해한 후 넘어가는 것이 좋을 것 같아 대략적인 순서를 구성해보았다.

우선 (1) 상품 상세 페이지 접속 후 -> (2)구매하기 버튼을 클릭할 시 -> (3)주문자 정보 입력 page가 나오게 되고,

(4)주문자 정보 입력 후 결제를 클릭 시 -> (5)결제창 및 결제완료 페이지가 호출된다.

그 후, (6)상품구매완료 페이지가 호출되며 ->** (7)구매상품목록을 확인할 수 있는 페이지가 호출되고 -> **(8)구매 결과 페이지가 호출되는 형식이다.

저장하는 알고리즘 역시 크게 생각해 본다면, (1) 결제 버튼 클릭 시 주문정보가 생성되고 -> (2)상품 구매 완료 시 주문 정보에서 주문 상태 값을 update 시켜준다.

(3)그 후, 결제 관련 정보 받아서 -> (4)저장된 주문 정보로 구매 상품 목록 및 결과 페이지를 호출한다.

돌아가는 로직은 전반적으로 이해하였고, 직접 코드를 짜보면서 깊게 이해해 보도록 하겠다.

🔖 html 코드 및 bootstrap을 활용한 스타일 작업의 상세한 설명은 표기하지 않겠다.

⌛ 주문 페이지 생성

1. 상세페이지 > 구매하기 버튼 생성 = 해당 구매하고자 하는 상품의 고유id값을 가지고 order 주소(구매 페이지)로 이동

---

2. 버튼 누릴 시 주문 가능한 페이지 API 생성(controllers > product.py) 값을 가지고 render_template 주소를 order_form.html page로 이동시킨다. (주문 페이지에는 상품 정보가 필요하므로 product 넘겨줌)

---

3. order_form.html 생성 및 구조작성 = html 코드 구조 및 bootstrap class를 이용하여 간단하게 폼을 생성한다.

📍 주의할 점은, 각 input에는 고유 id값 및 name값을 이용해 값을 전송시켜야 한다.

여기서, 우편번호 찾기를 클릭 시 주소를 입력하는 API을 다음에서 제공해준다.

다음 API 예제코드를 복사하여(사용자가 선택한 값 이용하기 -> 예제 코드보기), onlinestore 주문 폼에 맞춰 input값 및 button을 그대로 사용하면 된다. (script는 건드릴 것이 없다.)

⌛ 주문 API 생성 및 구현

1. 주문 생성 api = product정보가 필요하므로 product_id를 받은 후/order 및 post 방식 이용

order 함수형 선언 및 product_id를 주소에서 받아온다.

그 후 product에 대한 정보를 product_id를 가지고 찾아올 것이므로, 주문정보를 저장할 때 상품에 대한 정보 역시 저장한다.(어떤 상품을 구매한지 확인해야함)

---

= input으로 들어오는 배송지 정보와 주문자 정보를 받아올 때 사용

---

= order collection에 insert_one이라는 함수로 product와 form_data, user에 대한 정보를 저장할 것이다. (order.py file을 models 에 생성하여 사용할 것이다. 우선 Order 사용)

이 user는 check_login을 할 때 사용한 것이므로(로그아웃에서 사용) 그대로 가져온다. = 만약 로그인이 되어있다면 user정보를 가지고 사용할 것이고, 로그인이 되어있지 않다면 return 값으로 돌려보낼 것이다.

🔖 check_login 및 redirect_to_signin_form 사용위해 import 필요

---

2. models > order.py 생성 = order class 생성 후 db연결, insert_one method에 사용하여 product, form, user값을 받아온다.

그 후, form에서 전송된 data들을 받아와서 db에 저장시킨다.

---

3. order 활성화 = 생성을 했다면, 사용을 위해서는 반드시 import가 필요하다.

작업을 하면서 자주 까먹는 상황이 발생했고, 반드시 import가 필요하다!!!!

---

4. 주문 생성 API > return 값 생성 🔖 *현재 주문테스트는 주문요청 시 db에 값이 저장되는 것을 확인하는 용도이므로, 값만 제대로 전송된다면 주문완료 페이지로 이동시킬 것이다. *

render_template 요청 후 payment_complete.html page로 이동시켜준다.

---

5. payment_complete.html 생성 = 주문완료 title및 내용으로 간단하게 페이지 이동 확인 용도로 처리해준다.

---

6. form 전송 값 변경 = 어떤 상품을 구매할 것인지에 대한 고유 id값과 /order 로 action값을 요청시킨다.

---

7. 주문 시 비로그인 처리 확인 = 비로그인 유저가 주문 시 주문 페이지로 이동할 수 없도록 API에서 check를 해두었으므로, 로그인 후 주문을 해야한다.

---

8. 실제 주문 테스트 = 주소, 구매자 이름, 연락처 정보를 담아서 주문하기(form 전송) 버튼을 클릭 시 db에 data들이 저장된다. = 주문 요청 시 주문성공 페이지로 이동 = 실제로 db에 order.py 에서 담은 data들을 확인할 수 있다.

이처럼 주문자가 자신의 정보를 입력 후 주문을 요청할 시 요청된 data값들이 db에 정상적으로 담기는 것을 확인할 수 있다.

결제 모듈은 주문완료된 목록과 상세정보를 확인하는 페이지까지 생성 후, 작업해보겠다.

다음 시간에는 주문완료 목록 및 상세정보 확인 페이지를 만들어보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 권한부여

✍ 이전 시간에는 관리자(판매자) 와 구매자의 권한을 is_admin key값으로 구분하여 상품등록 페이지를 예시로 들어 테스트를 해보았다.

이제 구분할 수 있는 권한을 생성했으니, 각 페이지 및 기능들의 권한을 부여해 보도록 하겠다.

1. is_admin 권한 부여 = 상품 등록, 삭제, 수정, 수정 API 에도 적용을 시킨다.

하지만, 이전 테스트와 마찬가지로 redirect 되는 것보다 관리자를 제외한 나머지 사용자들에게는 보여지지 않는 것이 나을 것이다.

---

2. is_admin session 값 체크 = 상품 list page의 수정, 삭제 버튼의 경우 session is_admin 값이 true일 경우 보여주는 방식을 사용했다. = 관리자일 경우에만 보여지는 상태이다.

---

3. delete 완료 및 등록완료의 경우 redirect 추가

정리를 해보자면,

비로그인 사용자 및 일반 구매자의 경우 상품을 보고, 구매하는 행동만 가능하다.

관리자(판매자)의 경우 상품의 CRUD가 가능하다.

드디어!!! 다음 시간에는 상품을 주문하는 부분을 만들어보겠다!! 🎉

이번 기회에 상품 구매 프로세스를 완벽히 익히고, 결제모듈 연동 및 배포까지 구현하여 기능들도 점차적으로 추가하고, 스타일 작업 및 구조작업(fe)을 통해 여러 테마의 온라인 스토어를 배포시킬 것이다 😎

빠이팅 ^__^

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 사용자 구분 및 권한

✍ 사용자의 경우를 나누어 보겠다. 사용자는 판매자와 구매자로 구분할 수 있다. 판매자는 상품 CRUD가 가능해야하며, 구매자는 상품을 확인하고 구매하는 역할이다.

따라서, 판매자와 달리 구매자는 상품을 보거나 구매만 가능해야한다.

사용자를 구분하고, 각 사용자마다 권한을 부여해 요청을 제한해야한다.

우선, 판매자/구매자 > Users collection document > is_admin key값을 대입하여 true일 시 판매자, is_admin 값이 없거나 false일 시 구매자 로 구분할 것이다.

권한을 생성한 후, 상품등록 메뉴를 관리자일 경우에만 보여지게 작업해 보도록 하겠다.

🧨 관리자/구매자 유저 구분

1. mongodb Compass 접속 및 is_admin 값 부여(관리자) = 생성 시 string 값은 boolean으로 변경 후 생성한다.

is_admin 값으로 구분할 것이며, test@test.com id는 admin으로 권한 값이 주어진 것이다.

---

2. is_admin 으로 판단할 함수 생성(auth.py) = 우선 판매자와 구매자를 구분하기 위해서는 로그인 된 상태여야 하므로 check_login 함수를 호출한다. 만약, user가 존재하지 않는다면 false 값을 return 시켜준다.

반대의 경우 is_admin의 값이 존재한다면, 그 값을 return 시켜준다. ( boolean or false )

get 함수의 경우 is_admin이 존재하지 않는다면 오류를 표출하는 것이 아닌, false 값을 return 하도록 만들어준다.

---

3. is_admin import 및 사용 = is_admin이 아닐경우, 상품 list page로 redirect 시켜준다.

올바른 결과라면, test@test.com(관리자계정) 일 경우에는 상품 등록 페이지가 접속 될 것이고, 비로그인 및 일반 사용자의 계정일 경우에는 list page로 계속 redirect 되어 접속이 불가할 것이다.

하지만, 접속이 되지 않는 것 보다는, 차라리 등록 버튼이 보이지 않는 편이 더 나을 것 같아 숨기는 방향으로(관리자만 보여지게) 고민 후 작업해 보았다.

---

4. 로그인 시 세션정보 추가 및 import(controllers > user.py) = user가 is_admin일 경우 true값을 추가한다.

🔖 로그아웃의 경우에도 마찬가지이다. = is_admin의 정보를 날려준다(false).

---

5. is_admin session 값 구분

비로그인, 일반 구매자 계정으로 접속 시에는 상품등록 메뉴 자체가 보이지 않게 되며, url 로 접속시에도 막아두었으므로 상관이 없다.

관리자의 경우에만 정상적으로 접속이 되는 것이다.

현재 테스트를 위해 권한구분을 제대로 정리하지 못했는데, 다음 시간에는 적용이 필요한 부분들의 권한을 적용시켜보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 사용자 구분 및 권한(로그인/비로그인)

✍ 로그인 사용자와 비로그인 사용자 로 구분지을 수 있다.

로그인을 한 사용자는 상품을 구매하거나 로그아웃을 할 수 있지만, 로그인을 하지않은 사용자는 상품을 보는 것만 가능하다.

이 또한 구분 후 요청을 제한해야한다. 작업 전 굴러가는 로직을 생각한 후 작업해 보겠다.

우선,

로그인/비로그인 사용자 > session 존재유무에 따라 구분할 수 있겠다.

현재 세션으로 로그인 되었을 시 로그아웃이 나오고, 로그아웃 시 로그인이 보이도록 해두었다.

이와 별도로, session이 처리되지 않은 로그아웃 버튼을 하나 생성하여 미로그인 상태에서 로그아웃을 클릭 시 로그인 후 이용가능하도록 권한을 부여할 것이다.

🧨 로그인 유저 구분

1. controllers > auth.py file 생성 = user controllers(controllers > user.py) 에서 사용하여도 되지만, 로그아웃 뿐만이 아닌 등록 및 구매에서도 사용될 예정이므로 공통된 함수로 사용해 준다.

---

2. 로그인을 체크할 함수 생성
   📍 비로그인의 경우 = 로그인을 했는지 안했는지 session에 대한 정보를 가지고 확인. 즉, session에 user_id 값이 있는지 없는지 구분하고, 값이 없다면 false를 return(로그인 한 유저가 아니다.)

   ---

   📍로그인의 경우 = session에 있는user_id의 값을 가지고 user를 찾는다.

   ---

3. find_one 함수 생성 = user_id를 받아주고, _id값이 user_id와 같은 user를 찾게 된다. 그 후 user가 없다면 false를 return하고, 존재한다면 user값을 return 시켜준다.

   ---

4. auth.py > user 값 전달 = find_one 함수에 session id 값이 들어가면 user가 나오거나 false가 나오게 된다.
   check_login 함수를 사용할 때 최종 값은 user 또는 false 일 것이다.

   ---

5. controllers > user.py -> check_login 함수 실행 = check_login 함수 실행을 위해 import 도 포함

   ---

6. check_login을 할때마다 사용할 함수 생성 = login page로 이동시키기 위한 함수 생성 여기서 url_for 내부의 signin_form 의 경우 user controllers 에 미리 생성해 둔 코드이다. flash 도 추가하여 alert 후 이동되도록 처리해 두었다.
   

   ---

7. redirect_to_signin_form 함수 활용 및 import = user가 없다면 redirect 함수 실행 및 로그인 page 이동

   ---

8. 미로그인 유저가 로그아웃 클릭 시 확인 = 로그인이 되지 않은 유저기에 else에 걸려 flash 실행 및 로그인 페이지로 이동된다.

이렇게 로그인과 비로그인을 공통적인 함수를 생성하여 구분할 수 있게 만들어 두었다.

로그인 후 사용가능한 페이지를 구분하여 권한을 부여하면 될 것 같다.

다음 시간에는 판매자(관리자)와 구매자를 구분하여 권한을 부여해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 로그인

✍ 이메일 패스워드 체크 후 값이 유효한 경우 session id와 user id 를 저장하고, session id값을 web browser 에 전달한다.

이후, web browser는 요청을 할 때마다 session id값을 flask에 전달하고 session id값이 존재하면 login 상태로 판단하게 된다.

1. 로그인 API 생성 = route는 /singin 주소값 및 singin 함수 생성. form_data도 받아온다.

---

2. 받은 form data를 이용하여 로그인 판별 = sign_in 함수는 form_data의 email과 password 값을 check하여 정상적인 로그인이라면 user 의 정보를 가져올 것이고, 아니라면 로그인이 제대로 작동되지 않았다는 값을 return 시킬 것이다.

---

3. models > user.py sign_in 함수생성

---

4. user 찾기 = login 할 시 전달된 data email이 documnet에 존재한다면 users document에서 가져와서 user에 담는다.

---

5. 존재여부에 따른 처리방식 = 만약 email document data가 없다면 false값을 return 해 줄것이고, 존재한다면 다음순서인 password를 check 해 주어야 한다.

user의 password와 전달받은 password 의 값이 같지 않다면, return false를 시켜준다.

🔖 현재 check_password_hash 라는 값은 db에 저장될 password를 암호화 시켜주기 위해 사용한 것이다.

자세한 설명은 뒤에 게시될 것이므로, 그 값이 password 여부를 체크하는데 사용되었다 정도로 이해하고 넘어가면 될 것 같다.

참고)= 즉, 회원가입한 email이 없거나 password 가 일치하지 않으면 false 값을 반환할것이고, 둘다 일치한다면 찾은 document user 정보를 return 한다는 함수이다.

---

6. API에서 존재여부에 따른 처리 = 만약, user가 없다면 flash message 및 회원가입 페이지로 return 시키고(추후 html file 생성 예정)

존재한다면 session이용 (import 필요 = from flask import request, render_template, flash, redirect, url_for, session)

즉, session 정보에 user_id라는 key값으로 user id를 문자열로 저장한다는 의미이다.

로그인이 성공한다면, list page로 redirect 시켜준다.

---

7. password 암호화 (5번 순서 참고) = 기존 회원정보 db를 참고할 시 password 가 "1234" 로 가입되어 있다면 db에서도 "1234" 로 보여진다.

그러하여, 암호화 작업을 통해 회원들의 password 가 노출되지 않도록 암호화 시켜주는 작업을 해보겠다.

7-1. models > user.py file open 및 import = generate_password_hash -> 암호화된 password

= check_password_hash -> 암호화된 password check

---

7-2. 저장 시 암호화 처리

---

7-3. password 비교 check_password_hash 사용하여 기존 암호화된 password 와 전달받은 암호화되지 않은 password를 넣어 check 후 일치할 시 true return/ 일치하지 않을 시 false return

이렇게 암호화 작업까지 마친 후, 회원가입 진행 시 암호화된 password 가 db에 저장될 것이다.

---

8. login page API 생성 및 html file 생성

= page 내부의 form action 값만 signin으로 변경

---

9. 로그인 여부 파악 후 표시 = 로그인이 되지 않았을 때는 로그인 메뉴가 나타나야하고, 로그인이 되었을 경우에는 로그아웃 메뉴가 나타나야 한다.

if 구문 및 저장한 session 값으로 비교가 가능할 것 같다. 직접 구현해 보면서 코드를 작성해 보겠다.

= user_id 가 존재한다면 로그아웃, 존재하지 않는다면 로그인이 표시 될 것이다.

---

10. 로그인 시 user_id 출력 = db에 저장된 고유 id값이 출력될 것이다.

---

11. 로그아웃 생성 = signin 이 아닌, signout이 될 것이다.

---

controllers > user.py > route 생성 = 저장해 둔 이용권 정보를 없애면, 이용권을 주더라도 정보가 없다고 판단하여 자연적으로 로그아웃 상태가 된다. 로그아웃이 된다면 list 가 보이도록 redirect 시켜두었다.

즉, 로그인이 성공한다면 로그인 메뉴가 로그아웃 메뉴로 변경되고, 로그아웃을 클릭 시 session이 초기화 됨에 따라 로그아웃이 되고, 로그인 메뉴가 보이게 된다.

이렇게 로그인, 로그아웃을 구성하였다😎

다음 시간에는 회원관리, 사용자 권한과 관련된 부분을 구현해 보도록 하겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 회원가입

✍ 작업 전, 새로운 상품을 등록하는 로직처럼 새로운 사용자를 등록하면 크게 다를 게 없을 것 같다는 생각이 들었다.

결과적으로 회원가입은 상품 등록과 유사하다. 상품 -> 사용자가 되는 것이고, product에서 사용한 controllers 및 models 도 User로 세팅하면 되는 것이다.

새로운 상품 등록이 아닌, 새로운 사용자가 등록한다고 생각하면 쉽게 해결할 수 있으리라 판단했다.

1. blueprint 경로 세팅 = products 세팅 시와 동일하게 user도 생성해준다.

---

2. controllers > product.py copy 후 user.py 생성

---

3. 사용하는 import 만 남겨두고, product 값은 user로 변경

---

4. models > product.py copy 후 user.py 생성 = product가 아닌, user class 생성 (3번 항목의 3번째 줄 models > user.py 의 User Class 가 import 되는 것이다.)

---

5. app.py -> user blueprint 등록

---

6. 회원가입 등록 페이지 API 생성 = /users/form 입력 시 users/product_form.html 랜더링

---

7. 회원가입 data 전달 및 요청 API 생성 = form_data를 User class에 insert 시켜준다.(/models/user.py)

---

8. models > user.py insert_one 수정 = 지금까지의 흐름도를 이해하고 넘어가려고 한다

회원가입 정보 입력 후 회원가입 버튼 클릭 시 /users/signup 주소로 넘어감과 동시에 post방식(회원정보가 주소창에 보여지는것은 옳지 않음) 으로 User Class에 form_data를 던져준다.

그럼, User Class의 insert_one에서 form_data를 받아 해당 정보들을 users collection으로 생성 후 document를 집어넣어준다.

---

9. templates > user_form.html file 생성 = 파일 생성 후 form으로 넘어갈 action 값을 signup(controllers/user.py 에 만들어 둔 경로) 로 전송 및 항목에 맞게 form 내부 input 값 변경

---

10. data 전송 후 확인(mongodb compass) = 가입하고자 하는 이메일 및 패스워드 입력 후 form값을 전송 시(버튼 클릭 시) db에 users collection 생성 및 전송한 data 값이 들어오게 된다.

하지만, password 와 password 확인이 다를 경우에도 회원가입이 정상적으로 이루어졌을 것이며, 같은 email 로 회원가입 시에도 정상적으로 진행되었을 것이다. 또한 data를 입력하지 않은 상태에서 form 값을 넘길 경우에도 문제가 될 것이다.

당연하다. 내가 별다른 처리를 안했다(?) 이제 처리를 해보겠다 😉

---

11. data 유무 및 중복검사 체크 = 간단하게 if문으로 일치하지 않을 경우 넘어가지 못하게 방지하였고, html 코드 상에서 required 를 사용함으로 필수적으로 입력하도록 처리해 두었다.

하지만, 이메일 체크의 경우는 form_data의 이메일 존재여부를 파악한 후 data를 비교하여 처리해야 한다.

우선, 비교문을 작성한다.

---

= db에 같은 email이 들어온 것이 있는지 파악 후, 만약 있다면 email을 사용하면 안되므로 false 값을 반환하고, 없다면 true를 반환시킨다.

---

12. flash 사용 = 만약 flash를 호출한 message가 존재한다면 해당 message를 alert 창으로 띄워준다. (flash 구문 11번 참조)

🔖 구문 중 % 와 { 또는 } 사이에 공백이 없어야 한다.

하지만 error 가 발생할 것이다. 😵‍💫

session을 사용하여 작업하는 것인데, secret key가 없기 때문이다. 그러므로, app.py에서 secret_key를 설정해 주어야 한다. 그 후, user_form 에 만든 alert 가 불릴 수 있도록, flash 하단에 각각 render 시켜준다.

---

13. 회원가입 완료 후 list page 이동 = 우선 product blueprint 를 가져온다. redirect 를 시키기 위해서는 product 가 필요하기 때문이다.

---

= redirect 시 필요한 redirect 및 url_for import

---

= products redirect

이로써 회원가입 버튼을 누를 시 form data가 전송되며 몇가지 구문으로 값 비교 후 db에 저장될 것이다 🎉

다음시간에는 저장된 member 값을 활용하기 위해 로그인을 구현해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품 상세

✍ 상품 상세페이지는 수정과 많이 다르지 않다. 상품 정보 수정페이지는 특정상품의 고유번호(id) 를 주소로 받아서 MongoDB에서 해당하는 document 정보를 가져와서 product.html 과 함께 반환해 주었다.

마찬가지로, 상품정보를 html 에 넘겨서 보여주는 것이므로 쉽게 처리할 수 있을 것이라고 판단했다. (판단이 맞길 😅)

1. 상품 상세 정보 페이지 API 생성 = find_one method를 통하여 product_id를 가져온다.

---

📍 id가 들어가면 _id가 같은 document 를 가져와서 return 해주고(/modles/product.py)

---

정보가 불러와 지게 되는 것이다.

그 후 return template에 product.html file을 생성한다.

---

2. html file 구조 변경 및 style 작업(bootstrap) = 해당 bootstrap 내용은 앞전에도 다뤘으므로 따로 정리해서 올리지 않겠다. 쉽게 설명하자면 bootstrap의 card demo를 가지고 붙여넣은 뒤, data 값만 db에서 땡겨와 주면 끝이다. 😎 🔖 list page 에서도 view 페이지로 링크 이동이 되어야 하므로, href 값을 href="/products/{{product['_id']}}/detail" detail 로 이동되도록 설정한다.

드디어 CRUD가 가능한 상품 페이지가 끝이 났다!

반틈정도 갖춰진 상태인데, 회원가입 및 로그인도 작동이 되어야하고, 권한에 맞게 관리자만 상품을 삭제, 수정 및 등록을 할 수 있어야하며, PG사 결제도 추가하여야 하고, 사이트 배포도 남아있다. 😎😎

평소에 해보고싶었던 작업물인데, 개강 전에 작업할 수 있게 되어 행복하다 🎉 (회사에서도 코딩하고 퇴근하고도 코딩하려니 속이 안좋긴 하지만 재미는 있다 ㅎㅎ)

3째주부터 시작되는 대기중인 사이드프로젝트의 일정을 맞추기 위해서는 다음주까지는 끝내야 하지 않을까 싶다.

오류가 발생하더라도 빨리 처리해서 무사히 완료하고싶다.

다음 시간에는 member쪽 회원가입 및 로그인을 구현해 보겠다 !!

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품 수정

✍ 상품 수정은 등록과 매우 유사하다. 변경하고싶은 특정 상품의 고유번호를 주소값에 담고 update 주소를 정의한다. flask가 주소를 요청받으면 API 함수를 호출하고, 특정상품의 고유번호를 가진 product document 상품을 찾아 수정시켜 주는 것이다.

1. 상품 수정 API 생성 = route를 product_id/update 주소로 요청하며, update 함수를 사용함과 동시에 product_id값을 받아준다.

---

= 상품 등록과 유사하게 동일한 data 값을 받아온다. 하지만 등록과는 다른 점이 있다. 수정을 하는 경우에는 img file을 수정하지 않을 수도 있을 것이다.

수정을 하지 않는 경우에는 upload를 하지 않을 것이고, thumbnail 및 detail img가 아무것도 존재하지 않을 것이다.

그러므로, if문으로 존재여부를 파악하여 있다면 upload 시키도록 작업을 해주었다. 🔖 등록도 동일하게 if문으로 처리해준다.

---

하지만, 수정을 하지 않는 경우에는 if문이 동작하지 않고, 최종적으로 update_one 함수가 실행될 때 thumbnail_img_url 및 detail_img_url 을 정의할 수 없어 오류가 발생할 것이다.

---

이러한 상황을 예방하기 위해 기본적으로 정의를 해두어서 undefined 가 발생하지 않도록 변수를 정의해 두었다.

---

그 후, 데이터를 받아와서 저장해야 하므로 update_one 이라는 함수를 만들어 저장하겠다. 필요한 data는 어떤 상품을 삭제할 지 파악해야 하므로 고유 id값과(product_id), form_data, thumbnail_img_url 과 detail_img_url 값을 받아오겠다.

---

2. update_one 함수 생성 (models > product.py)

📍 update_one 함수 생성(요청한 data값 받아옴) 및 mongodb connect

---

📍 생성의 경우 insert_one으로 정보들을 저장하였으나, update_one 함수를 사용하여 $set 부분에 정보를 전달하는 코드를 작성한다.

---

📍 어떤 document(상품)을 수정할 것인지 구분이 필요하므로, 전달받은 ObjectId 값으로 product id를 찾는다.

---

📍 기존의 정보와 새로 들어온 정보들이 구별되어 저장되어야 한다. (수정하는 사람의 입장에서는 data를 변경하지 않을 수도 있으므로 빈값으로 update 되지 않도록 해준다.)

---

** 📍 img 처리 ** 이미지가 존재한다면, new_product 에 img를 url 로 수정해준다. 즉, 새로운 수정된 img 의 url값을 넣어준다는 의미이다.

---

** 📍 return 값 생성 **

---

3. 상품 page 생성

** 📍 상품 정보 수정 페이지 API 생성 ** = 어떤 상품을 수정할 지 파악해야 하므로 고유 id값/edit 으로 주소를 정의하였다. find_one 이란 수정 page에 접속했을 때 어떤 정보가 기존에 작성이 되어있는지 확인 후 수정을 거쳐야하므로 id값을 넘겨서 document를 가져올 것이다.

---

** 📍 models > product.py -> find_one 생성 ** = id값 및 db 사용하겠다고 선언하였다. 즉, _id가 넘겨준 id과 같은 document를 찾아서 가져온다. 그 후, product document를 return 시 (controllers > product.py) return 받은 document로 html file과 함께 web browser에 보여질 것이다.

---

** 📍 Compass 접속 및 product document id값 주소창 입력 ** = html file에 출력구문을 작성하였다면, 해당 product document의 정보값이 출력 될 것이다.

---

** 📍 product_edit.html file 커스텀 ** = 등록폼과 유사한 구조 및 스타일이며, 등록과 다른 부분은 input에 data가 포함된 상태인 것이다.

data를 추가하기 위해서는 name으로 예시를 들자면 ** value="{{product['name']}}" ** 값을 추가시켜주면 가져온 data값이 뿌려진다.

update 를 클릭 시 action 값은 ** /products/{{product['_id']}}/update ** 주소로 전달되고 controllers > product.py -> 상품 정보 수정 API가 호출이 되면서 return 값 또한 출력 될 것이다.

---

** 📍update 후 list page 이동 및 import ** = redirect를 product 안에 있는 get_products 함수를 호출시켜준다는 의미이다. 즉, 수정이 되면 상품 리스트 조회 page 로 이동시켜준다는 코드이다.

= 이와 같이 정상적으로 list page로 redirect됨과 동시에 data가 수정된 부분을 확인할 수 있다.

🔖 list_page의 edit 버튼에도 ** /products/{{product['_id']}}/edit ** edit 페이지로 이동시켜주는 링크를 추가시켰다.

오늘따라 집중이 잘 되지않아 등록과 거의 유사한 부분이 많았음에도 불구하고 몇번이고 반복해서 들었던 것 같다 😵‍💫

그래도 확실히 이해를 하고 넘어갈 수 있어 다행인 것 같다 ^^...........

다음 시간에는 상품 detail page를 작업해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품 삭제

✍ 등록된 상품을 list에서 확인 후 삭제하는 기능을 구현해 보도록 하겠다. 큰 logic을 구상해보면 상품 삭제를 위해 버튼을 클릭 시 삭제하고자 하는 상품의 고유id값을 매개변수로 던져주고, 삭제가 진행되는 과정이다.

1. 상품 삭제 API 생성 = 상품 삭제 요청을 받기 위해서는 주소를 요청해야 한다. 삭제의 경우에는 /product_id/delete 형식의 주소를 지니고 있다. 그 후, delete 함수 생성 및 삭제 요청 시 던져줄 product_id 라는 매개변수를 생성한다. product_id 란 /product/특정상품1개의 고유번호/delete 를 나타낸다.

= 해당 랜덤으로 생성되는 고유 id값을 나타내는 것이다.

---

2. delete_one 함수 생성 -> controllers > product.py -> models > product.py = 하나의 products document 를 삭제해 주는데, 어떤 document를 삭제해 줄것인가에 관한 부분을 작성해 주어야 한다.

즉, _id 가 objectID를 가지고 있는 document 를 삭제할 것이다.

ex) 파란운동화를 삭제하고자 한다면 objectId 가 62e90f.....de 인것을 삭제하겠다는 것이다.

🔖 또한, objectId를 사용하기 위해서는 bson import 가 필요하다. -> from bson import ObjectId

---

3. product_id 전달 = 전달한 product_id 가 models > product.py 의 id가 되고, objectId에 포함되고 _id가 objectID인 product document 하나를 삭제하게 된다.

---

4. 삭제 요청 버튼 생성 = 고유 id값을 주소로 요청시킨 삭제기능이 포함된 버튼 하나를 생성시킨다.

---

5. 삭제 확인 = 삭제하고자 하는 상품의 고유id값이 주소값에 출력되면서 return text 역시 출력되었다. 즉, 삭제되었다는 의미이며 db상에서도 당연히 삭제가 완료되었다.

이로써 삭제기능까지 끝이 났다 !😎

실질적으로 돌아가는 logic을 파악하며 미리 한번 작업을 해보고, 포스팅을 하면서 두번 작업을 거치니 훨씬 더 깊게 이해가 가는 것 같다.

다음시간에는 상품 정보를 수정해보도록 하겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품 List

✍ 이전 시간에서는 db에 저장된 document 정보들을 불러왔다면, 이번 시간에는 불러온 정보들을 실제 온라인스토어의 list 형태로 구조화 시킨 후 실제 값들을 넣어 보겠다.

1. html 구조 작성(bootstrap 활용) = 이전 posting에서도 설명했듯이 필자가 현업에서 사용하는 fe 업무에 포함되어 있는 내용이고, 따로 공부할 필요가 없다고 판단하여 도출된 결과물만 기록하도록 하겠다. 간단한 순서이지만, 표기해본다면 bootstrap demo들을 download 받은 후 include 경로만 맞춰주면 demo page와 동일하게 뿌려진다.

---

2. 반복문 작성 = 같은 구조의 list가 뿌려지므로, 여러번 반복할 필요 없이 반복문으로 처리하여 db의 document 개수만큼 뿌린다. ex) db 내부의 document 개수가 5개라면, 5개가 동일한 구조로 뿌려진다. 🔖 for문을 열어줬다면 반드시 닫는 코드도 필요하다. 빼먹지 않도록 주의 !!

---

3. db 실제 data값 뿌리기 = img를 upload 하고 난 후, 저장된 위치와 주소를 MongoDB에 저장해 두었는데, product 내부의 thumbnail_img, name, price 값을 호출시켜 실제 data를 출력시킨다.

---

4. 공통요소 include = 각 page별로 html을 정의하는 기본 구조와 header들은 같기 때문에, 여러번 반복해서 재사용하기에는 효율이 떨어진다. 그러므로, include를 사용하여 한페이지에 공통된 내용을 넣어두고, 호출하는 방법으로 작업해 보겠다. = base.html file을 생성 후, 공통된 부분이 아닌 contents 영역 위치에 block content 요소를 하나 생성해 준다. 즉, 각 페이지마다 바뀌는 contents 요소가 들어온다는 의미이다. = base.html (공통된 요소가 포함된 file) 을 extend 시켜준 후, 각 page마다 바뀌는 contents 영역을 block content로 열고 닫은 후 그 안에 각 페이지의 고유 내용을 넣어주면 끝이다.

---

5. 결과물 = extend를 시킨 후, 상단 메뉴에 현재 생성된 file인 상품 리스트 및 상품등록 메뉴를 구성해두었다. 작업물이 도출된 후, 추후에 디테일하게 스타일 작업이 들어갈 것 같다. 😎

다음 시간에는 상품 리스트에서 상품을 삭제하는 API를 생성해 보겠다.

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품조회

✍ 상품등록 방식과 유사하다. flask 에서 주소로 products/list(get) 접속 할 때, products.html file을 전달시킬 것이다.

1. API 생성 = product route 의 주소는 /list(get 방식은 default 이므로 표기안함) 로 설정하였고, 함수명은 get_products 로 정의하였다.

즉, list 주소를 입력 시 get_products 함수가 호출 되고, 상품 리스트를 땡겨와야 한다.

말보다는 역시 설명이므로 그림으로 흘러가는 logic 을 구상해 보겠다. ... 사실 나만 알아볼 거 같긴 하다 ^^;; 😅 간단하게 보자면, db > products > collection > document(상품명, 가격, 이미지 등등...) 을 뽑아와서 list에 뿌려준다고 생각하면 될 것 같다.

🔖 Product collection 안에 있는 내용을 작성할 때는, models > product file에서 작성해 준다.

---

2. staticmethod 생성 = product collection 안에 있는 모든 document 들을 find() 로 가져온다. = 그 후, find 함수를 작성시켜준다.

---

3. 상품 list 정보 출력을 위한 html file 생성( templates > products.py) = blueprint로 products 를 mapping 해 두었으므로, /products/list 주소 호출 시 products.html file의 내용이 보여지게 된다.

---

4. product 정보 출력 = product1 변수에 products(DB 안 documents 들의 내용을 담은 변수) 를 담아준다. = html file에서 products에 있는 배열 요소들을 개수만큼 for문을 돌려서 하나하나 출력을 시켜준다. = document 요소 하나하나가 출력이 되었다.

결과물과 같이 db에 저장된 list들을 출력시켜주었다.

다음시간에는 실제 store처럼 보이도록 html 구조 및 css 작업을 통하여 list 처럼 보이게 만들어 보겠다!

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. 상품등록

✍ form > input 값에 맞게 상품이름, 가격, 설명, 이미지 등 첨부 후 등록버튼을 클릭 시 값이 전송되는 logic으로 구성되어있다.

1. API 생성 = get 방식(default)으로 form을 호출 시 등록 화면이 보이도록 호출하는 API를 생성하는 것이다.

즉, /form 주소로 flask 요청을 하게 되면, product_form.html file을 반환해 주겠다는 코드이다.

🔖 render template 사용을 위해서, import 필요함 -> from flask import request, render_template

---

2. templates folder 생성 및 > product_form.html 생성 = browser 상으로 확인을 해보기에 앞서, /form을 mapping 시켜두었지만, 앞전에 blueprint로 주소창 앞에 /products 를 잡아두었으므로, 실질적인 주소는 "/products/form" 을 입력 시 호출 될 것이다.

---

3. html 태그 작성 = 상품 등록 버튼을 submit으로 전송 시, /products/regist 주소값으로 등록을 요청한 값이 전달된다.

값이 주소창에 노출되는 것 보다는 privacy 한 것이 나으므로 post값으로 전송하며 upload(img) 입력값도 포함되어있으므로 multipart 값을 추가한다.

---

4. 전송 값 확인(error - 각 input에 name 값이 없을 경우) 🧨 3번 이미지에서는 각 input마다 name값이 포함되어 있어 정상적으로 값이 전송되고, db에 저장되지만 name값이 없을 경우를 가정하여 테스트 해보았다.🧨 = nonetype 및 filename error가 발생한다. product controller에서 filename이 존재하는데, upload 시 filename이 없다는 error 인 것이다.

즉, 값이 전달되지 않았다는 것이다. 각 입력값이 어떠한 변수값을 가지고 전달이 되어야하는데, 변수가 저장되지 않아 전달받을 때 아무것도 없다고 인식을 하는 것이다.

request.form으로 요청을 받을 때, 해당 name을 찾아서 전송받은 값을 저장할 수 있게 되는 것이다.

---

5. 전송값 입력 및 확인(success) = name값을 각각 부여한 후, db에 저장하기 위해 data 값을 전송 시 저장되는 것까지 확인할 수 있다.

⌛ 현재 등록 폼은 아무런 스타일도 잡혀있지 않는 html 구조이다.

이 폼을 css(아마 bootstrap을 사용할 예정) 로 스타일 작업을 해주어야 하는데, 현업에 포함되어있는 작업내용이라 따로 공부할 필요가 없다고 판단했다.

별도의 과정설명 없이 작업 후 결과물만 보여주는 것으로 대체하겠다.⌛

2. 결과

= 보이는 바와 같이 깔끔하게 구현해 내었다. bootstrap을 이용하여 작업하였는데, 나는 bootstrap을 현업에도 사용하지 않고, 그다지 선호하지 않는다.

단순한 프로젝트인 경우 간단하게 보이는 바와 같이 클래스만 땡겨서 스타일을 구축해 낼 수 있지만..

1. 실질적인 프로젝트에서의 시안은 boostrap을 활용하기에 어렵다.
2. 기존 초기화 코드인 reset과 겹치는 class가 많다.

장점도 물론 뛰어나지만, 프로젝트를 진행하는데에 있어서 단점이 더 많다고 판단하여 css 및 sass를 활용하여 component를 구축하고 module 별로 땡겨쓰는 방식으로 작업을 하고 있다.

이와 같이 상품 등록을 browser 상에서 확인해 내었고, 다음 과정은 상품등록으로 저장한 상품을 list page에 뿌려보도록 하겠다.

이제 점점 재밌어지고 있다!!!!!😎😎

이 글은 PROJECT LION : 호코치 강사님의 강의를 들으며 참고한 글입니다.

작업 중, 개발과정 정리 및 issue가 되었던 부분들을 공유 및 기록하고자 작성하게 되었습니다.

1. img upload

✍ 이전 시간에는 판매하고자 하는 상품의 고유 값 및 정보들의 값을 db에 저장하였다.

추가적으로 list에 뿌려질 thumbnail img 및 view page의 img 도 파일 경로를 생성한 후 지정된 filename으로 저장하여 값을 넘겨보도록 하겠다.

1. request file 경로 생성(thumbnail 및 detail img) = 해당 img file을 upload 하게 되면, request.files 라는 곳에 thumbnail_img 및 detail_img 라는 file의 정보를 얻을 수 있다.

   file 정보의 경우 어딘가에 저장 해 주어야 하는데, file은 text가 아닌 말 그대로 file 형태이기 때문에 python file 과 같은 file 형태로 저장해 주어야 한다.

---

2. img_file upload 위한 함수 생성 = 각 코드의 흐름에 맞게 순서대로 주석처리 하였지만 다시한번 복습할 겸 순서를 나열하며 코드를 재작성 해보겠다.

🧸 함수 내부 순서 🧸 2-1. upload 시킨 날짜를 확인하기 위해, timestamp 함수 사용 2-2. 생성된 file 이름에는 생성한 날짜와 이름을 추가한다. 2-3. upload 시키고자 하는 path 설정 2-4. directory 존재 유무를 파악하여 해당 directory에 path 및 filename upload 2-5. path 경로에 file save 2-6. 저장된 path 경로 > img file mongoDB upload

---

3. upload file 함수 호출 및 img 값 db전달 = upload_file 함수 호출 및 요청한 img 값을 thumnail_img_url 및 detail_img_url 변수에 저장 후, db 에 전달하기 위해 insert_one 내부에 값을 전송해준다.

---

4. 요청 후 전달받은 값 db 전송 = db에 보내줄 값을 받아서, insert 시켜준다(user값은 임의로 admin으로 세팅했으며, 생성날짜 및 수정날짜는 filename을 저장할 때 처럼 timestamp 값을 정수 type으로 생성하여 db에 담아주었다.)

---

5. datetime, secure_filename, os 불러오기 = models > product.py file도 datetime 을 사용했으므로, 동일하게 datetime import 필요

---

6. upload 테스트 = Insomnia 접속 후, file 형태로 thumbnail img 및 detail img 첨부 후 전송

---

7. static/uploads folder 생성 확인

---

8. MongoDB 전송 값 확인

이로써 img file이 db에 정상적으로 저장 된 것을 확인할 수 있다 😎

상품등록 API에 대한 구현을 완료하였다!

현업에서는 fe 업무만 수행하고 있어, 실질적으로 값을 저장하고 넘기는 작업은 처리해 보지 못했는데, 실제로 코드를 작성하고 값을 넘기는 작업을 수행해보니 재밌는 것 같다. (아직 코드는 손쉽게 작성하지는 못할 것 같다 😂)

다음시간에는 상품등록 page를 구현하여 실제 web browser에서 등록이 가능하도록 해보겠다.