프로젝트/Recipository60 [Dev] 23.02.27. 댓글 pagination Footer를 마지막으로 포트폴리오로 대략적으로 작성할 기본적인 기능을 완성했다고 생각했는데, 역시 또 하나 빠진 것이 있었다. 바로 댓글에 대한 pagination이다. 게시글 목록을 pagination 없이 로딩하는 것과 동일하게, 한 게시글에 작성된 모든 댓글이 한 번에 로딩된다. 필자는 이에 버튼을 눌러 댓글을 몇 개씩만 더 가져올 수 있도록 만들고 싶다. (스크롤로 작업해봤더니 개인적으로 마음에 들지 않았다.) 작업 content.html 댓글 댓글 더보기 (중략)------------------------------------------------------------------ 기존에 fragments 에 두 가지 div tag를 만들어놓고 값에 맞게 다른 항목을 rendering 하는 것에.. 2023. 2. 27. [Dev] 23.02.26. 게시글 이미지 로딩 (임시) 사실 이전에 게시글과 함께 작성하여 게시글 목록에 띄우기 위한 file upload와 관련해서 임시로 작성한 게시글이 있다. 문제는 그렇게 file이 저장되고 저장한 이미지에 대한 경로까지도 table에 저장되는데 해당 경로로 이미지를 요청했을 때는 이미지가 보이지 않을 뿐더러 바로 다음과 같은 오류가 발생했다. Not allowed to load local resource: file:///C:/Users/kyuhwan/Desktop/Projects/blah~blah Server의 외부에 file을 저장하는 공간이 있다고 가정하고 필자의 local folder에 이미지를 저장하도록 하고 그 path를 게시글 data의 image path로 저장하도록 했는데, 화면에 필요한 image를 rendering .. 2023. 2. 26. [Dev] 23.02.22. 게시글 검색 기능 이리저리 작업하다가 게시글 페이징 작업이 마지막이라고 생각했는데, 생각해보니 검색 기능을 작업하지 않았다는 것이 생각났다. 이번 게시글에는 검색 기능을 작업했던 내용을 기록해보려고 한다. 작업 아이디어 아이디어는 특별하지 않다. Client에서 html form tag를 통해 보내는 request parameter를 활용할 것이며, 보내는 request parameter의 값에 따라 동작하는 query를 다르게 하도록 하는 것이다. 작업 navibar.html 제목 작성자 내용 검색 보통은 client 에 대한 작업 이미지 설명은 거의 하지 않았던 것 같은데, 이번에는 하나 기록할 것이 있어서 이미지를 가져왔다. 필자는 검색 keyword를 입력하고 검색을 요청한 뒤 그에 대한 응답을 받을 때, 검색 시.. 2023. 2. 22. [Dev] 23.02.20. 게시글 목록 페이징 처리 (Pagination) 아마 이번 페이징 작업이 당분간의 마지막 작업이 될 것 같다. 처음 계획에는 카테고리 별로도 구분하는 것도 있었으나, 그것은 게시글 목록에 대한 페이징 처리 이후 조금씩 작업하기로 결정했다. 현재 게시글 목록은 따로 페이징 처리가 되어있지 않은 채로 모든 게시글의 목록을 불러오고 있다. 하지만 필자는 몇 개씩을 그룹으로 묶어 페이징 처리를 하고 싶다. 이를 위해 JPA 강의 중에 간단한 Paging 방법을 소개하는 것까지 살펴보고 작업을 시작했다. 아이디어는 간단하다. 페이징 UI를 가장 먼저 만들고, 그에 대한 요청을 GET 방식으로 주어서 게시글 중에 N번째 부터 몇 개씩만을 조회하도록 하는 것이다. 늘 그래왔듯 이번에도 알 수 없는 오류에 직면하거나 필자가 생각하지 못한 방향으로 흘러갈 수는 있겠으.. 2023. 2. 20. [Dev] 23.02.17. 중복된 조회의 원인과 그 해결 (feat. OSIV) 현재 일부 게시글 data를 조회하는 query 가 동작할 때, 두 번씩 동작하는 것을 테스트 과정에서 몇 번 보게 되었다. 이에 대한 원인을 분석하고, 수정하는 방안을 모색해보려고 한다. 게시글을 모두 작성하고 난 뒤 가장 앞에 작성하고 있지만, 결과적으로 필자는 OSIV Filter 를 활용하지 않기로 했다. 원인 분석 사실 필자는 '영속성' 에 대해서 아직도 명확하게 알고 있지 않다. 그나마 알고 있는 점은 영속성이라는 것이 하나의 Transaction(트랜잭션) 안에서만 유지되는 것이 일반적이라는 것이다. 그래서 추정한 것이 실제로 어딘가에서 해당 조회를 하고 있다는 생각인데, 그 주인공이 바로 Interceptor였다. 필자는 이전에 게시글을 수정하거나 삭제하는 요청에 대해서 로그인 한 사용자가.. 2023. 2. 17. [Dev] 23.02.06. 게시글 삭제 시 query 변경 (feat. modify delete query) 이전 게시글에서 회원 탈퇴 시 data를 삭제하는 과정에 대해 작업한 것처럼 기존의 삭제 과정에 대한 query도 변경해볼 것이다. 지난 게시글에서의 작업은 다음과 같았다. 두 번의 사용자 data를 조회하는 select query 각각 1개 (총 2개) 삭제하고자 하는 게시글 data를 조회하는 select query 1개 (총 1개) 타 게시글의 댓글 작성자를 수정하는 update query 1개 댓글, 게시글의 참조 링크, 게시글 data를 삭제하는 delete query 각 1개 (총 4개) 삭제할 사용자의 권한을 조회하는 select query 1개 삭제할 사용자의 권한, 사용자의 data를 삭제하는 delete query 각 1개 (총 3개) 위 항목에서 동일한 과정을 거쳐야하는 것은 2번의 .. 2023. 2. 6. 이전 1 2 3 4 5 6 ··· 10 다음
