-> 회원에 관련된 업무를 수행하겠음
-> 14장에서는 파라미터로 넘기지 않고 Path variable이라는 새로운 annotation을 controller측에서 선언하고 받는방법을 살펴봄

-> rest방식의 약속임

-> json 데이터를 꺼내서 map이나 일반 dto에 저장할 수 있는 코드를 만들어둠

-> 경로에 있는 변수를 int page로 받기



-> controller가 응답을 만들어서 넘겨주는데 controller는 service의 결과를 바로 반환하고 있으니까








-> 등록이 끝나고 나서 데이터 살아있지만 지워버림

-> 남자에 들어간 checked는 해제함


-> 초기화 함수를 짜보기

-> 지금은 아무일도 안함





-> service에 가서 service에 try catch가 있으니까

-> 선언하기!!











->콘솔창 open 중복되는 id등록하기

-> json으로 못 넘어옴





-> 이미 사용중인 id입니다 처리하기전에

-> flush하고 close는 안전하게 넣기




-> 예외 사유를 명확하게 안내를 해주는것이 가능하다(언제 어떤 예외가 발생하는지 확인을 먼저하기!!)

(경고창 alert으로!!)





-> 줄바꾸기 싫어요 하면 print로 바꾸기







-> 언제 뭐가 나올지 모르니까 확인하기!!


-> 같은 패키지에 있으면 상속관계임



-> 이유없이 상황발생시 : 상속관계 잘못된것


중복체크 다녀온 뒤에 insert 수행하는 구조로 바꿈 -> 중복 체크 코드가 들어가있었으면 됨
(안해도 됨)

회원에 관련된 처리를 service로 구현 : id중복 체크해서 예외처리하지 않음

-> 조회버튼 누르면 데이터 끌어올려주고 원하면 수정할 수 있게 해주기!!




-> 이버튼의 memberNo값을 꺼내와서 사용을 하자 !!

상세보기를 하고싶으면 식별할 수 있는 식별자가 넘어가야함

-> 프론트 작업만해서 새로고침하면됨

★★★ 다 이렇게 해라 (event)!!!

-> REST API 에서는 다 json임

-> null값이 온다고해서 error를 적으라는 건 아님

-> 번호가 최종적으로 도착해야할 곳은 마지막 단계 memberMapper.xml임





-> 메소드이름이 id와 같아야함






-> 전달 안될리가 없다고 가정시 바로 받으면 됨

-> 안보내면 오류남, 번호가 없으니까 null값 -> null값을 정수로 바꾸려고 하면 안됨

radio의 value가 ''(따음표) 2개 ++(더하기) 2개
-> 이값을 가진 아이의 property를 true로 바꾼다

ServiceImpl부터 거꾸로 돌아가면서 하나씩 수정하기

상세조회 확인후 -> 조회를 하면

-> 조회했을때 id는 property추가로 사용못함 -> disabled
-> readonly(읽기전용)

-> 조회상황에 하나 더 추가하기



-> 버튼 추가한거 복사해서 Init으로 데리고 가서 복붙




-> front쪽 연습 병행함


-> 수정할 사람의 정보를 넣어두기

-> 못보던 애가 생겼으니까 초기화 블록에도 추가작업하기!!

-> 4개의 데이터는 수정할 데이터로 만들어서 보내는것이 가능함


-> map으로 해도 됨













-> restapi 방식에서 수정의 타입은 put임

-> 4개의 데이터를 json으로 만들어서 보내주기!!
(json으로 반들어서 memberDTO로 받을 수 있음)

-> 수정된 내용은 상세보기쪽은 안해도 됨

-> function memberlist
-> 새로 삽입된 결과를 보기 위해서 page를 1로 바꾸기

-> 호출부 복사해서 호출하기!

-> 목록도 바뀜(이름, 성별, 주소도 바뀌어야함)

-> 상단의 삭제는 나만 지우는것 : 탈퇴 개념
-> 전체선택 삭제 : 여러개를 지울 수 있는것(한번에 여러개 지우기)

-> 이거보고 진행하기!!
-> PathVariable쓰기

-> 조회 후 삭제

-> 버튼 remove도 disabled 처리해놓고

-> 버튼 remove false되살려주면됨


-> Get과 유사한방식, POST방식이 아니라

-> 실제로 PUT이 유사한방식임

-> /(슬래쉬)로 구분하는건 어려울 것 같고 432 ,(콤마)로 분리해서 삭제할 데이터 쭉 전송하면 한번에 (String)으로 받아서


-> 역으로 하나씩 구현하는 과정

-> 체크가 되었는지 안되었는지 확인가능







-> 복붙해서 호출하기


-> 삭제할 아이들의 번호는 배열에 모았음

-> 이 구조로 진행하기!

ajax 넘어가기전에 controller에서

-> 자바 스크립트는 쉬움
(배열의 요소를 묶어주는 함수가 있음)

-> join(webstudy에 있음)

-> 문자열로 바로 나옴
-> path variable로 붙이면 됨(다 string임)
-> body쪽에 data로 포함시켜서 requestbody로 받으면 안됨

-> 본문에 포함시키는것이 허용이 안됨
=> 주소창에 붙여서 동작하는 방식 써야함(여러개를 붙일려면 customerizing하는수밖에 없음)

seriver입장에서는 주소가 똑같음

-> 한명삭제는 member
-> 여러명삭제는 members

-> membernumber list

-> 아직은 안만들어서 오류가 난것

-> membernumberlist를 list로 바꾸기





-> WHERE절 만들때 WEHRE태그도 지원함
LIST에 꺼내쓸때 하나씩

-> List에 있는

(4,3)은 foreach가 가져갔는데 item 값은 고대로 빼서 하나씩 뺀 item의 이름 적어주기

-> IN은 연산자에 포함시키기

-> 물론 Where태그를 꼭 써야만 foreach를 쓸 수 있는건 아니지만

-> where MEMEBER_NO 쓰고 이렇게 써도 상관없음




-> index에서는 응답을 responseData의 remove result === 1하면 x


-> insert 삽입 쪽에 수정할 부분이 있음

-> 정상이라고 가정하면 Writer만들고

-> 위치 조정하기!!

-> try catch를 안에서 또 넣어서 하기!!





-> 경고메시지 안쓴것 같아서

-> 잠깐 지우고 되돌려 놓기

출발로 연결해서 INDEX에 ,(콤마)로 연결된 DATA를 분리해서 하나씩 심어넣었음





-> 안되는 이유 ? 앞뒤로 작은따음표 문자열 처리가 붙어서 String 이 처리가 안된것






-> 이런식으로 접근이 가능하다(이해하는 정도로)
-> 상황에 따라서 #을쓰거나 $을 쓰거나 구분하지 않음
-> 일반적으로



-> 이거 보낼때는 $달러로 묶어서 표기할 예정임

-> 쿼리문의 구성요소로 값이 나올것

★★★

-> 이걸로 공부하기!!

-> 항상 둘다 하는게 아니라 상황에 따라서 조건을 매길 것이라 가정하면 틀림(만족하면 포함한다는 뜻)
-> 만약에 만족을 안하면

-> WHERE다음에 바로 AND(문법이 안맞음)

-> 만약에 이게 없어지면

베포

(경로보기) C:

베포를 서버에 올리고 싶다

-> c드라이브 파일에 webapp

실행

-> 톰켓을 켤때 실행하는 파일

-> 컴퓨터가 서버임(톰켓을 설치한)
-> 그래서 지금실행할것은 배치파일임

종료

1.14장 프로젝트를 하나로 만든다 -> Build (war 파일 : 와르파일)

js servlet으로 봤던 베포할 수 있는형태로 바뀜
(Maven Build써서 하는방법도 있음)
-> export 메뉴에 war와르 메뉴가 있음

-> 목적지 : 바탕화면에 저장하기

-> 확장자 강제로 붙음

-> 14장이 하나의 파일로 생김

서버 중지시키기

-> 서버 delete로 빼기

-> access허용하면 console창에서 보던 log들임
(한글 깨져도 오류가 있다면 볼수있음)

-> nullpointexception 보이지 x
-> 끄지 말고 최소화시키고

-> 실행할 때 필요한 라이브러리들
-> form.xml에 정의한 것들

-> 알아서 체크해서 가져온다 (dependency 의존관계 확인가능함)

-> project의 property로 가서 assembly로가서
library로 보내겠다
-> maven으로 받아온것들 class들 resource들 어디로 보냈는지 체크가 되어있음

-> views에 jsp에 모여있음
-> 베포가 끝난것

주소쳐서 확인하기!!

-> app14라고 하면안되고 변수처리해서 변했음
-> contextpath는 war와르파일의 이름으로 정식으로 war(와르)를 만들때 contextpath의 version 붙여서 자동으로 만들어줌
(임의의 이름으로 war와르 파일만들어서 베포하고 실행하면 접속됨)
-> 우리도 tomcat톰켓에 올려놓은 베포상황


-> 등록한 정보다 선생님 DB로 들어오는것(등록하면)
-> 지금은 선생님 자리가 server임


-> 진짜 서버에 올려서 베포하는과정과 크게 다르지 않음
-> 서버는 멀리있으니까 와르파일 이동하는것이 조금 어려움
(startup 켜는 명령을 알아야하고)
=> "수동베포" 방식임