4주 (2024-12-02~2024-12-08)

12/02

1. 모든 브랜치 병합 테스트 -> 작업 완료
   (feat/member, feat/board, feat/room, feat/reservation, feat/payment, comm/env)
   • 브랜치 병합 후 정상 작동 테스트 끝.
   • 회원가입 > 로그인 > 각 비즈니스 RESTful API URL 테스트 가능.
   • <application.properties>, <config>, <build.gradle> 부분에서 기본에서 각자 추가 사용한 코드가 있어서 취합하기 시간이 걸렸음.
2. react front user 개인 작업 -> 작업중
   • bootstrap을 사용하여 기본적인 UI 작업 끝. 
   • chat gpt와 열심히 대화해서 클라이언트에서 결제시 결제 로직을 어떻게 구현해야할지 구현해나감.
   • 작업 내용
     • 결제버튼 클릭시 select를 했는지 유무 판단.
     • 결제버튼 클릭시 select-paypal을 선택을 하면 해당 payapl 결제 api 호출.
     • paypal 결제 api 호출. /api/checkout/{reservationId}
       • reservationId를 변수처리하여 해당 결제 내역의 ID가 알아서 적용되어 api 호출하게 함.

12/03

1. [ react front admin ] - 관리자 페이지 공통 ROUTER 수정 -> 작업 완료
   • 최신 버전으로. create-browser-router
   • 수정 후 알리기. git pull 로 변동사항 가져오면 됨.
   • 어차피 각 서버별로 작업중인 파일은 변경되지 않으니까.
2. [ react front admin ] - 관리자페이지 spring boot와 통신 시켜놓기 -> 작업 완료
3. [ react front user ] - payapl 결제 요청 후 성공 시 성공페이지로 이동하게 하는 거 생각해보기. -> 보류
   • paypal 결제 요청시 결제화면이 뜨는 것 까지 성공.
4. [ react front admin ] - 관리자페이지 테이블 구현 및 pagination 구현 기능 찾아보기. -> 내일. 오늘못함.

12/04

1. [ react front admin ] - 관리자페이지 테이블 구현 및 pagination 구현 기능 찾아보기. -> 내일. 오늘 못함.
   • 테이블과 pagination UI는 react bootstrap을 사용해서 구현.
   • api 호출해서 payment 테이블에 있는 데이터를 불러와서 pagination이 동작하도록 만들어놓으면 됨.
2. [ springboot payment ] - 결제 안되는 부분 원인 찾아서 해결하기. -> 원인 찾음. 해결방안 찾는 중.
   • 어제 postman으로 reservationId를 가지고 결제를 하는데 에러가 발생함.
   • order가 정상적으로 발급되고 결제 버튼까지 했을 때 넘어가는데 이때 SUCCESS가 안됨. 중간에 백단에서 문제가 발생한 거 같음.

12/05

1. main 브랜치에 dev 브랜치 merge -> 굳이 할 필요 없다고 생각들어서 안함.
   • boardDTO 파일명이 다르게 나와서 원인 찾고 feat/board 브랜치에서 boardDTO 파일만 가져올 수 있는 명령어 있는지 알아보기.
2. [ back-end ] feat/payment api 및 쿼리문 수정 -> 몇가지만 수정.
   • 결제 생성은 성공.
   • 결제 상태 수정, 결제 삭제, 결제 전체 불러오기 api 다시 테스트 해야함.
3. [ front-end-admin ] UI 디자인 작업 -> 작업중. 내일 마저 하기.
   • pagination 기능 찾아보기.
   • UI는 bootstrap 사용

12/06

1. [ fornt-end-admin / back-end ] pagination 작업
   • [ back-end ]에서 할 일 -> 작업 끝.
     • 쿼리문 작성 및 테스트
       • 특정 테이블의 목록 전체 갯수 조회 하는 쿼리문 작성
       • 특정 테이블의 내가 지정한 갯수만큼 출력되도록 쿼리문 작성
     • page, size에 따른 DTO 생성
       • page, size, totalPages, totalElements, content 필드 생성.
       • int, int, int, int, long, List<paymentDTO>
     • controller 작성
       • @RequestParam 어노테이션 사용
       • name="page", name="size" 값 받기.
       • 각 defaultVlaue값 지정. 1페이지당 10개씩 보여줄 거니가 defaultValue="1", defaultValue="10"
       • page, size 아규먼트를 service로 보내고 값 반환받아오기.
     • service 작성
       • 파라미터로 받은 page, int로 작업.
       • int offset, int totalElements, int totalPages, List<paymentDTO> 작업
         • int offset은 첫번째 페이지는 01,02,03,04,05,06,07,08,09 로 시작, 두번째 페이지는 10,11,12,13,14,15,16,17,18,19 가 되고 세번째 페이지는 20,21,22,23,24,25,26,27,28,29 이렇게 되듯 앞자리가 바뀐다. 이걸 offset으로 하기.
         • int totalElements는 총 목록의 갯수이다. mapper를 통해 총 갯수 값 가져오는 쿼리문을 실행시켜 해당 값을 가져오기.
         • int totalPages는 pagination 아래 번호들이다. 그래서 totalElements(총 갯수)에 size(한 페이지에 보여줄 목록 개수)를 나누기. 그 다음에 나머지 값을 올려줘야 나머지 페이지들을 볼 수 있다. 그러니까 글 갯수가 33개인데 나머지 값을 버리면 아레 페이지네이션 번호가 1,2,3 까지밖에 없어서 31,32,33 번 글을 볼 수가 없다. 그래서 나머지를 무조건 ceil을 통해 반올림 시켜줘야한다.
         • List<paymentDTO> content = mapper에 offset과 size를 보내서 모든 목록들을 가져오기.
         • PageDTO 새 인스턴스를 생성해서 page, size, totalPages, totalElements, content값을 담아서 controller에 return 시켜주기.
     • mapper 작성
       • offset과 size를 파라미터로 받는 List<paymenDTO> 타입의 method 작성
       • 전체 목록 갯수의 값을 가져올 수 있는 method 작성
     • mapper.xml 작성
       • 처음에 테스트하면서 작성한 쿼리문 적용.

12/07

• 관리자페이지
  • 삭제 버튼 클릭시 확인 알림창 띄우기 -> fin
  • 확인 알림창에서 삭제를 클릭하면 payment와 orders 페이지에서 해당 item이 삭제되게 만들기 -> fin
  • 쿼리문과 back-end(spring boot) 소스코드 수정작업 -> fin

12/08

• 관리자페이지
  • 수정 버튼 클릭 시 상태 변경 API 호출 -> fin
  • 결제 상태 변경시 DB에 업데이트 되도록 작업 -> fin
  • 결제 상태 변경시 DB에 업데이트 되면서 orders에도 상태 변경이 되도록 작업. -> fin