개발블로그by페페

1)이니셜라이저 다운인텔리제이에서 열고 롬복 설치 확인application.properties 에 application name 및 port 설정 test hello controller 작성 후 application 돌려서 체크(@RestController로 한다) 롬복 확인롬복 @G / @S / @ToStringuserDto에 age name 넣고 jason으로 반환되는지 확인실행하면 Target resources에 userDto가 생긴다 - 2) SQL 설치 및 연동    https://ee2ee2.tistory.com/entry/MySQL-MySQL-%EC%84%A4%EC%B9%98%EC%8B%9C-3306-Port-Error-The-specified-port-is-already-in-use [Da..

JS에서 RequestBody로 들어오는 요청 / DTO는 : BR에러시 메세지를 담아서 직접 처리해준다 또 실제 서비스 사용하여 오더진행시 익셉션시에도 모델 필요없이 new ReponseEntity에 에러메세지(e.getMSg or 그자리에서 생성)를 넣어 반환한다 (멤버폼 제출시) - @Valid DTO로 검증되는 BR에러는 그냥 폼 자체에서 에러메세지 처리하므로 다시 폼 리턴만 해주면 된다 - 세이브멤버 Exception발생시 e.getMessage를 model에 넣어준다 - (로그인에러시) - 모델에 에러메세지 만들어서 넣어준다 - 다시 멤버로그인폼 리턴 - (오더) - BR에러 발생시 -> 스트링빌더에서 겟필드에러 sb에 담아서 -> 모델 필요없이 RE - 오더서비스 오더 사용시 : 모델 아니고..

만들어진 것의 데이터는 DB에서 가져와서 뷰에 공급해야하므로 당연히 model은 세 메서드 모두 항상 필요 페이지 기반 보고이므로 Optional page 역시 3개 모두 필요 principal ItemSearchDTO @PathVariable 아이템매니지 어차피 admin만 이용하는 문서이므로 X 모두 보여주고, 필요한 것 필터해야하므로 필요 메인 모든 아이템을 보여주므로 필요X 모두 보여주고, 필요한 것 필터해야하므로 필요 메인은 왜 안달렸나? 오더히스토리 principal.getName()으로 주문을 특정해야 하므로 사용 단일 사용자의 모든 주문을 보고해야하므로 필요X 쿠팡처럼 필터시 필요 -> 나중에 시간나면 리팩터링

(흩어져서 기능 처리) 컨트롤러 메서드는 사용되는 기능을 전부 커버하는 것은 아니고, 몇개는 뷰 페이지에서 자바스크립트를 사용, 체크박스, 서브밋 버튼 등으로 직접 처리되고 몇개는(주로 로그인 검증 관련 + 사용하지않을 페이지 뷰 리졸버) securityConfig에서 처리된다. - (나머지 컨트롤러 메서드는 19개) -> 외운다 멤버 - 회원가입폼, 폼제출, 로그인폼, 로그인에러폼 / 1~4번 메인 - 메인, 아이템, 페이지뷰 / 5번 오더 - 아이템 직접주문, 오더 캔슬, 오더히스토리 / 6 7 8번 카트 - 카트 페이지, 카트 아이템 주문, 카트에 아이템 넣기, 아이템 삭제, 아이템(수량) 업데이트 / 9 ~ 13번 아이템 - (어드민) 생성폼, 세이브제출, 수정폼, 업데이트제출, 아이템 관리페이지..

- git 터미널 사용으로 github에 올린다 - commit history -> push - 처음파일 init 필요 / add - 처음 리포지토리 이메일 네임 설정 Origin mater pull이랑 branch? - 신입 당겨오기 Clone git->복사코드 폴더 폴더 안써주면 자동으로 프로젝트 이름 폴더로 들어감 - master에 올리지 않고 공간 새로 파주기 (코드 작성했으나 테스트 전에는 수합x) Git push origin freshman 이후 pull request : 마스터에 갈 수 있게 허락해주세요 Branch 마음에 안들면 review change Merge pull request Add - comiit - push 상대가 작업한 파트가 있을때 Add - commit - pull - ..