리주의 프로그래밍 공부

포트폴리오를 다듬기 위해 작업하던중 참고할게 생겨서 github 프로젝트 repository에 들어갔다. 그런데.. 있어야할 파일들이 중간중간 안보였다. >> 초반에 깃허브 사용에 미숙했던 나머지, commit 후 push를 잘못한것 같다. local에만 했다던가, 새로운 파일들을 제외하고 push했다던가.. 과거의 내가 무슨 잘못을 한건지 모르겠다. 문제는 프로젝트가 제대로 끝난줄 알고 local에 있는것들을 모두 삭제했다는 것이다. 크나 큰 실수였다. 커밋내용에는 ~~ 적용, ~~~수정이 적혀있는데.. 들어가면 파일들이 없다. 복습하는 마인드로 다시 추가해야겠다. JavaMailSender에서 setFrom에 shop@shop.com 을 사용하니 네이버 메일함에는 메일이 오지않았다. >> 같은 코드로..

RESTful한 코드를 위해 상품 수정 부분을 수정하면서 수많은 에러를 만났다. >> 결론은 파일 전송은 PUT으로 사용하지 못한다는 것이다. 여러 검색을 통해, 웹브라우저가 PUT(과 DELETE)을 인식하지 못하여, httpMethodFilter 설정을 통해 put과 delete를 처리해주는건 일찍 알게 됐다. 이 설정을 해둔 뒤에, putmapping으로 등록된 상품 수정을 하기 위한 코드 수정을 계속 해왔다. 하지만, 이상하게도 프론트엔드에서 보내는 form Data에는 값이 잘 들어가 있는데, 백엔드로 오면 값이 다 사라져 있었다. 이걸 해결하고자 여러 코드들을 참고하여 수정해봤지만, 돌아오는건 에러 또는 비어있는 객체뿐... 오늘에서야 다른 분이 아래 참고 사이트를 보여주셔서, 여태까지 한 일..

RESTful하게 코드를 수정하려다보니, 하루종일 에러만 보는것 같다. >> PUT Method를 사용하려다 onClick="submit()"이라는 생각치 못한 복병을 만나 오늘 아침을 날렸다. 위와 같은 방식으로 스크립트의 함수명을 submit으로 하게되면 태그로 인해 스크립트의 submit이 아닌, form의 submit으로 실행된다. 따라서 함수명을 달리해주거나, 버튼을 태그 밖으로 위치시켜야한다. 으로 날리는게 아닌, ajax를 사용해 값을 전달하고자 했다. >> 하지만 상품 수정의 경우에는 파일까지 같이 들어가기에, serialize를 사용하는 대신, 하나씩 append를 해줘야했다. 하지만 결과적으로는 에러가 나서 다시 내일 수정해야한다.

RESTful 을 적용하여 코드를 수정중이다. >> @PathVariable를 사용해서 url의 값을 가져올 수 있다. 유저의 정보를 가져올 때에 /user/{userID} 이 나을지, /user 해서 스프링시큐리티로 저장된 정보를 불러올지, 뭐가 나은지 모르겠다. put, delete는 form:form 태그를 사용해서 hidden type으로 보내줘야했다. redirect 시에 뒤에 따라오는 parameter를 숨기기위해, redirectView를 선언해서 setExposeModelAttributes를 false로 설정해줬다. 기존 코드를 바꾸려하니 힘든게 아니다. 내가 짠 코드지만, 확실히 규칙이 없어서 읽기도 복잡했다. 수정과 삭제 부분을 위해 다른 사람의 코드를 더 찾아봐야겠다. >> PUT 과..

인증 이메일을 좀 더 빨리 보내고, 이메일을 보냈다는 팝업을 빨리 띄우게 하기위해서 async를 사용했다. >> 스프링을 사용중이라 @Async를 쓰면되지만, 단순히 이것만 쓰면 안되고, taskExecutor를 @Bean으로 만들어줘야했다. 아직도 async를 완벽히 이해하지는 못해서 계속 찾아보면서 공부해야겠다. 회원가입 페이지의 css부분이 마음에 들지 않는다. >> 최근 프론트엔드 개발자들과 협업하고 있는 프로젝트를 통해서 그나마 css를 조금은 볼줄 알게되었지만, 아직 이부분까지 수정할정도로 시간이 여유롭지 못하다. 아쉬운 부분이다. 협업을 시작하면서 느낀거지만, 백엔드와 프론트엔드의 명확한 구분선이 있을까?라는 생각이 들기 시작했다. >> 혼자서 쇼핑몰 홈페이지를 구현해보면서 자바스크립트에 대..

HttpSession으로 유저정보를 불러오던 과정을 모두 Principal 로 바꿔 유저 아이디를 가져왔다. >> 어려운 작업은 아니었다. 오히려 바꾸고나서 아이디를 가져오는게 더 편해졌다. aside에 있는 로그인 정보에 따른 숫자는 다시 인터셉터를 사용했다. >> 'ROLE_USER'가 필요한 view들은 /customer/user/** 형식으로 'ROLE_ADMIN'이 필요한 view들은 /admin/** 으로 계층을 나눠놨기 때문에 설정이 용이했다. 관리자에게 필요한 aside 숫자들은 아이디가 필요없기 때문에, HomeInterceptor에서 설정해주었다. 스프링 시큐리티도 세션이다보니, 로그인 정보가 유지되지 않아 가만히 있다가 권한이 필요한 구간으로 넘어가려할 때, 에러페이지로 넘어간다. >..

현재 스프링 시큐리티를 적용하여 홈페이지를 개편중이다. 부딪힌 문제 >> 이제까지 세션으로 권한 체크와 유저 정보를 가져왔는데, 이걸 다 바꿔주어야한다. > 많은 jsp 페이지와 컨트롤러를 바꿔줘야한다. 아이디 저장기능도 스프링 시큐리티의 핸들러를 사용하여 다시 구현해야한다. 스프링 시큐리티를 사용하면 보안 문제도 인증 및 권한 문제도 편해진다. 하지만 이는 처음부터 설정할때 해당하는 말인듯하다. 기존에 세션으로 구현했던 홈페이지라 모든걸 바꿔야한다. 이런걸 보면 홈페이지 리뉴얼 작업은 아예 처음부터 시작하는게 맞지않나 싶다. 쇼핑몰 홈페이지도 처음부터 제대로 구현하고 싶으나, 지금까지 해왔던걸 복습할겸, 내 코드를 남의 코드로 보는것처럼 수정하는것도 좋은 경험일듯하여, 시간은 더 걸리겠지만 끝까지 해보..

어제부터 프론트엔드 개발자들과 처음으로 협업을 하는 새 프로젝트를 진행하게 됐다. 이 쇼핑몰보다 더 나은 결과를 위해서 무작정 부딪히기 전에, 생각을 좀 더 많이하고 있다. 그 과정에서 이 쇼핑몰 홈페이지는 정말 막무가내로 짜여진 코드 덩어리라는걸 느꼈다. 그래서 당분간은 지금까지 짠 코드를 정리하면서 최적화할 예정이다. 처음부터 다시 만드는것보다 내가 만들어놓은 코드를 되돌아보며 수정하는게 나에게 더 도움이 될듯싶다. 패키지 정리 >> dao 정리 : Interface와 Imp한 파일 두개를 하나로 합치기 mapper 정리 >> entity에 따라 분리하기 계획 >> spring security 적용하기