![[21] 기본적인 웹 게시물 관리 - 검색처리](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FkHnLb%2FbtqAJggR89S%2F1dMEX7QtkPIzaObOKXH8ak%2Fimg.jpg)
1. 검색 기능과 SQL
게시물의 검색 기능은 다음과 같이 분류 가능하다.
- 제목/내용/작성자와 같이 단일 항목 검색
- 제목 or 내용, 제목 or 작성자, 내용 or 작성자, 제목 or 내용 or 작성자와 같은 다중 항목 검색
검색 항목은 제목/내용/작성자와 같은 단일 항목 검색과 제목 or 내용과 같이 복합적인 항목으로 검색하는 방식이 존재한다. 게시물의 검색이 붙으면 가장 신경 쓰이는 부분은 역시 SQL 쪽이다. 오라클은 페이징 처리에 인라인뷰를 이용하기 때문에 실제로 검색 조건에 대한 처리는 인라인뷰 내부에서 이루어져야 한다. 단이 항목의 검색은 검색 조건에 따라서 칼럼이 달라지고, LIKE 처리를 통해서 키워드를 사용하게 된다. 만일 2페이지에 해당하는 데이터를 '제목'으로 검색하고 키워드는 'Test'라고 한다면 다음과 같이 작성될 수 있다.
- 검색조건 : 제목(title), 내용(content), 작성자(writer)
select
*
from
(select /*+INDEX_DESC(tbl_board pk_board) */
rownum rn, bno, title, content, writer, regdate, updatedate
from
tbl_board
where
--변경부분
title like '%Test%'
and rownum <= 20
)
where rn > 10;
단일 항목은 인라인뷰 안쪽에서 필요한 데이터를 가져올 때 검색 조건이 적용되어야 하기 때문에 where 문 뒤에 검색 조건이 추가되고, rownum 조건이 뒤따르게 하면 문제가 없다.
1-1. 다중 항목 검색
문제는 2개 이상의 조건이 붙는 다중 항목의 검색이다. 예를 들어, 제목이나 내용중에 'TEST'라는 문자열이 있는 게시물들을 검색하고 싶다면 다음과 같이 작성될 것이라 예상한다.
select
*
from
(select /*+INDEX_DESC(tbl_board pk_board) */
rownum rn, bno, title, content, writer, regdate, updatedate
from
tbl_board
where
--추가된 부분
title like '%Test%' or content like '%Test%'
and rownum <= 20
)
where rn > 10;
그러나 구문자체는 이상은 없지만 실제로 동작 시켜 보면 10개의 데이터가 아니라 많은 양의 데이터가 나오는 것을 볼 수 있다.
이렇게 많은 양의 데이터가 나온 이유는 위 SQL 문에서 AND 연산자가 OR 연산자보다 우선순위가 높기 때문에 'ROWNUM이 20 보다 작거나 같으면서 내용에 'Test'라는 문자열이 있거나 제목에 'Test'라는 문자열이 있는' 게시물들을 검색하게 된다. 제목에 'Test'(내 경우에는 한글로 테스트!) 라는 문자열이 있는 경우는 많기 때문에 위 그림과 같이 많은 양의 데이터를 가져오게 된다.
따라서, AND와 OR이 섞여있는 SQL을 작성할 때에는 우선순위 연산자인 '()'를 이용해서 OR 조건들을 처리해야 한다.
select
*
from
(select /*+INDEX_DESC(tbl_board pk_board) */
rownum rn, bno, title, content, writer, regdate, updatedate
from
tbl_board
where
--추가된 부분
(title like '%Test%' or content like '%Test%')
and rownum <= 20
)
where rn > 10;
2. MyBatis의 동적 SQL
SQL문에서 느끼는 점은 검색 조건이 변하면 SQL 내용 역시 변하기 때문에 XML이나 어노테이션과 같이 고정된 문자열을 작성하는 방식으로는 제대로 처리할 수 없다는 사실이다. 다행히 MyBatis는 동적 태그 기능을 통해서 SQL을 파라미터들의 조건에 맞게 조정할 수 있는 기능을 제공한다. MyBatis의 동적 태그는 약간의 구문을 이용해서 전달되는 파라미터를 가공해서 경우에 따라 다른 SQL을 만들어서 실행할 수 있다.
2-1. MyBatis의 동적 태그들
MyBatis는 기존의 iBatis에서 발전하면서 복잡했던 동적 SQL을 작성하는 태그들이 많이 정리되어서 다음과 같이 몇 가지의 태그들만을 이용한다.
- if
- choos (when, otherwise)
- trim (where, set)
- foreach
<if>
if 는 test 라는 속성과 함께 특정한 조건이 true가 되었을 때 포함된 SQL을 사용하고자 할 때 작성한다. if 안에 들어가는 표현식은 OGNL 표현식을 이용한다. 좀 더 자세한 내용은
https://commons.apache.org/proper/commons-ognl/language-guide.html
Apache Commons – Apache Commons
Welcome to Apache Commons Apache Commons is an Apache project focused on all aspects of reusable Java components. The Apache Commons project is composed of three parts: The Commons Proper - A repository of reusable Java components. The Commons Sandbox - A
commons.apache.org
<choose>
if와 달리 choose는 여러 상황들 중 하나의 상황에서만 동작한다 Java 언어의 'if~ else'나 JSTL의 <choose> 와 유사하다. 이 때 <otherwise>는 위의 모든 조건이 충족되지 않을 경우에 사용한다.
<trim>, <where>, <set>
trim, where, set은 단독으로 사용되지 않고 <if>, <choose>와 같은 태그들을 내포하여 SQL을 연결해 주고, 앞 뒤에 필요한 구문들 (AND, OR, WHERE 등)을 추가하거나 생략하는 역할을 한다.
<foreach>
foreach는 List, 배열, 맵 등을 이용해서 루프를 처리할 수 있다. 주로 IN 조건에서 많이 사용하지만, 경우에 따라서는 복잡한 WHERE 조건을 만들 때에도 사용할 수 있다.
3. 검색 조건 처리를 위한 Criteria의 변화
페이징 처리에 사용했던 Criteria 클래스의 의도는 단순히 'pageNum'과 'amount'라는 파라미터를 수집하기 위해서이다. 페이징 처리에 검색 조건 처리가 들어가면 Criteria 역시 변화가 필요하다!
검색 조건을 처리하기 위해서는 검색 조건과 검색에 사용하는 키워드가 필요하므로, 기존의 Criteria를 확장할 필요가 있다. 확장 방법으로는 상속 방법을 이용하거나 직접 Criteria 클래스를 수정하는 방식을 생각 해 볼 수 있는데, 예제에서는 직접 Criteria를 수정하겠다.
1) Criteria 클래스 수정
Criteria 클래스는 type과 keyword 라는 변수를 추가한다. getter/setter는 Lombok을 통해서 생성하고, getTypeArr은 검색조건이 각 글자 (T, W, C)로 구성되어 있으므로 검색 조건을 배열로 만들어서 한 번에 처리하기 위함이다. getTypeArr()을 이용해서 MyBatis의 동적 태그를 활용할 수 있다.
3-1. BoardMapper.xml에서 Criteria 처리
1) BoardMapper.xml은 기존의 getListWithPaging()을 수정해서 동적 SQL을 처리한다.
검색 조건이 총 3가지 이므로 총 6가지의 조합이 가능하지만, 각 문자열을 이용해서 검색 조건을 결합하는 형태로 하면 3개의 동적 SQL 구문만으로도 처리를 할 수 있다. <foreach>를 이용해서 검색 조건들을 처리하는데 typeArr이라는 속성을 이용한다. MyBatis는 원하는 속성을 찾을 때 getTypeArr()과 같이 이름에 기반을 두어서 검색하기 때문에 Criteria에서 만들어둔 getTypeArr() 결과인 문자열의 배열이 <foreach>의 대상이 된다. (MyBatis는 엄격하게 Java Beans의 규칙을 따르지 않고, get/set 메서드만을 활용하는 방식이다.)
<choose> 안쪽의 동적 SQL은 'OR title........ OR content... OR writer...' 와 같은 구문을 만들어내게 된다. 따라서 바깥쪽에서는 <trim>을 이용해서 맨 앞에서 생성되는 'OR'을 없애준다.
위의 동적 SQL은 상황에 따라서 3개까지 SQL을 생성한다. (title, title or content, title or content or writer)
동적 SQL은 경우에 따라서 여러 종류의 SQL이 생성될 수 있으므로 제대로 동작하는지 반드시 여러 번의 확인을 거쳐야만 한다. 기존에 BoardMapperTests를 만들어 두었으니 이를 이용해서 테스트 코드를 작성한다.
2) BoardMapperTests 클래스에 코드를 추가한다.
@Test
public void testSearch() {
Criteria cri = new Criteria();
cri.setKeyword("새로");
cri.setType("TC");
List<BoardVO> list = mapper.getListWithPaging(cri);
list.forEach(board -> log.info(board));
}
testSerch()는 Critera 객체의 type과 keyword를 넣어서 원하는 SQL이 생성되는지 확인하기 위함이다. 중요한 것은 실행 결과가 아니라 실행할 때 만들어지는 SQL이다.
<sql> <include>와 검색 데이터의 개수 처리
동적 SQL을 이용해서 검색 조건을 처리하는 부분은 해당 데이터의 개수를 처리하는 부분에서도 동일하게 적용되어야만 한다. 이 경우 가장 간단한 방법은 동적 SQL을 처리하는 부분을 그대로 복사해서 넣어줄 수 있지만, 만일 동적 SQL을 수정하는 경우에는 매번 목록을 가져오는 SQL과 데이터 개수를 처리하는 SQL 쪽을 같이 수정해야 한다.
MyBatis는 <sql>이라는 태그를 이용해서 SQL의 일부를 별도로 보관하고, 필요한 경우에 include 시키는 형태로 사용할 수 있다.
1) sql 태그안으로 trim 태그들을 모두 옮긴다. (select 문 밖으로 옮긴다!)
2) select 문 안에는 아래와 같이 include 태그를 집어 넣는다.
<sql> 태그는 id라는 속성을 이용해서 필요한 경우에 동일한 SQL의 일부를 재사용 할 수 있게 한다.
4. 화면에서 검색 조건 처리
화면에서 검색은 다음과 같은 사항들을 주의해서 개발해야 한다.
- 페이지 번호가 파라미터로 유지되었던 것처럼 검색 조건과 키워드 역시 항상 화면 이동 시 같이 전송되어야 한다.
- 화면에서 검색 버튼을 클릭하면 새로 검색을 한다는 의미이므로 1페이지로 이동한다.
- 한글의 경우 GET 방식으로 이동하는 경우 문제가 생길 수 있으므로 주의해야 한다.
4-1. 목록 화면에서의 검색 처리
목록 화면인 list.jsp 에서는 검색 조건과 키워드가 들어 갈 수 있게 HTML을 수정해야 한다.
1) views 폴더 내의 list.jsp를 수정해서 페이지 처리 바로 위쪽에 아래의 내용들을 추가한다.
수정된 HTML을 보면 페이징 처리를 위해서 만들어둔 <form> 태그에 <select>와 <input> 태그가 추가된 것을 볼 수 있다.
<form> 내 <button>의 기본 동작은 submit 이므로 별도의 처리 없이 검색이 되는지 확인한다. 항상 테스트는 영문과 한글을 모두 테스트해야 한다.
Chrome 브라우저는 한글로 검색하는 경우에 주소창에는 한글이 깨지지 않고 나오지만 실제로는 그림에 있는 박스의 내용물처럼 전송된다. IE 에서는 박스의 내용과 동일하게 출력이 되는 것을 볼 수 있다. 검색이 처리된 후에는 몇 가지 문제가 있다는 사실을 알게 되는데
1) 예를 들어, 3 페이지를 보다가 검색을 하면 3페이지로 이동하는 문제
2) 검색 후 페이지를 이동하면 검색 조건이 사라지는 문제
3) 검색 후 화면에서는 어떤 검색 조건과 키워드를 이용했는지 알 수 없는 문제
들이 남아있는 것을 볼 수 있다.
검색 버튼의 이벤트 처리
여러 문제들 중에서 검색 버튼을 클릭하면 검색은 1페이지를 하도록 수정하고, 화면에 검색 조건과 키워드가 보이게 처리하는 작업을 우선으로 진행한다.
1) list.jsp 검색 버튼의 이벤트 처리
var searchForm = $("#searchForm");
$("#searchForm button").on("click", function(e){
if(!searchForm.find("option:selected").val()){
alert("검색종류를 선택하세요");
return false;
}
if(!searchForm.find("input[name='keyword']").val()){
alert("키워드를 입력하세요");
return false;
}
searchForm.find("input[name='pageNum']").val("1");
e.preventDefault();
searchForm.submit();
});
브라우저에서 검색 버튼을 클릭하면 <form> 태그의 전송은 막고, 페이지의 번호는 1이 되도록 처리한다. 화면에서 키워드가 없다면 검색을 하지 않도록 제어한다.
검색 후에는 주소창에 검색 조건과 키워드가 같이 GET 방식으로 처리되므로 이를 이용해서 <select> 태그나 <input> 태그의 내용을 수정해야 한다.
2) list.jsp에서 검색 조건과 키워드 보여주는 부분
<select> 태그의 내부는 삼항 연산자를 이용해서 해당 조건으로 검색되었다면 'selected' 라는 문자열을 출력하게 해서 화면에서 선택된 항목으로 보이도록 한다.
페이지 번호를 클릭해서 이동할 때에도 검색 조건과 키워드는 같이 전달되어야 하므로 페이지 이동에 사용한 <form> 태그를 아래와 같이 수정한다.
3) list.jsp <form> 태그 수정
검색 조건과 키워드에 대한 처리가 되면 검색 후 페이지를 이동해서 동일한 검색 사항들이 계속 유지되는 것을 볼 수 있다.
4-2. 조회 페이지에서 검색 처리
목록 페이지에서 조회 페이지로의 이동은 이미 <form> 태그를 이용해서 처리했기 때문에 별도의 처리가 필요하지 않는다. 다만 조회 페이지는 아직 Criteria의 type과 keyword에 대한 처리가 없기 때문에 이 부분을 수정해 줄 필요가 있다.
1) get.jsp 페이지 수정
4-3. 수정/삭제 페이지에서 검색 처리
조회 페이지에서 수정/삭제 페이지로의 이동은 GET 방식을 통해서 이동하고, 이동 방식 역시 <form> 태그를 이용하는 방식이므로 기존의 <form> 태그에 추가적인 type과 keyword 조건만을 추가한다.
1) modify.jsp에 코드를 추가한다
수정/삭제 처리는 BoardController에서 redirect 방식으로 동작하므로 type과 keyword 조건을 같이 리다이렉트 시에 포함시켜야만 한다.
2) BoardController.java 클래스에 코드를 추가한다.
@PostMapping("/modify")
public String modify(BoardVO board, @ModelAttribute("cri") Criteria cri, RedirectAttributes rttr) {
log.info("modify:"+board);
if(service.modify(board))
rttr.addFlashAttribute("result", "success");
rttr.addAttribute("pageNum", cri.getPageNum());
rttr.addAttribute("amount", cri.getAmount());
rttr.addAttribute("type", cri.getType());
rttr.addAttribute("keyword", cri.getKeyword());
return "redirect:/board/list";
}
@PostMapping("/remove")
public String remove(@RequestParam("bno") Long bno, @ModelAttribute("cri") Criteria cri,
RedirectAttributes rttr) {
log.info("remove........" + bno);
if(service.remove(bno))
rttr.addFlashAttribute("result", "sucess");
rttr.addAttribute("pageNum", cri.getPageNum());
rttr.addAttribute("amount", cri.getAmount());
rttr.addAttribute("type", cri.getType());
rttr.addAttribute("keyword", cri.getKeyword());
return "redirect:/board/list";
}
리다이렉트는 GET방식으로 이루어지기 때문에 추가적인 파라미터를 처리해야 한다.
modify.jsp 에서는 다시 목록으로 이동하는 경우에 필요한 파라미터만 전송하기 위해서 <form> 태그의 모든 내용을 지우고 다시 추가하는 방식을 이용했으므로 keyword와 type 역시 추가하도록 아래와 같이 관련된 JavaScript 코드를 수정해야 한다.
3) modify.jsp의 일부
수정/조회 화면에서 어떤 작업을 하던지 다시 목록 페이지로 검색 조건이 유지되는지 확인해야 한다.
UriComponentsBuilder를 이용하는 링크 생성
웹 페이지에서 매번 파라미터를 유지하는 일이 번거롭고 힘들다면 한 번쯤 UriComponentBuilder라는 클래스를 이용해볼 필요가 있다. org.springframeword.web.util.UriComponentBuilder는 여러 개의 파라미터들을 연결해서 URL의 형태로 만들어주는 기능을 가지고 있다.
URL을 만들어주면 리다이렉트 하거나, <form> 태그를 사용하는 상황을 많이 줄여줄 수 있다. 검색 조건을 유지하는 org.zerock.domain.Critera 클래스에 링크를 생성하는 기능을 추가한다.
1) Criteria 클래스에 일부를 추가한다.
public String getListLink() {
UriComponentsBuilder builder = UriComponentsBuilder.fromPath("")
.queryParam("pageNum", this.pageNum)
.queryParam("amount", this.getAmount())
.queryParam("type", this.getType())
.queryParam("keyword", this.getKeyword());
return builder.toUriString();
}
UriComponentBuilder는 queryParam()이라는 메서드를 이용해서 필요한 파라미터들을 손쉽게 추가할 수 있다.
getListLink()를 이용하면 BoardController의 modify()와 remove()를 다음과 같이 간단하게 정리할 수 있다.
@PostMapping("/modify")
public String modify(BoardVO board, @ModelAttribute("cri") Criteria cri, RedirectAttributes rttr) {
log.info("modify:"+board);
if(service.modify(board))
rttr.addFlashAttribute("result", "success");
return "redirect:/board/list" + cri.getListLink();
}
@PostMapping("/remove")
public String remove(@RequestParam("bno") Long bno, @ModelAttribute("cri") Criteria cri,
RedirectAttributes rttr) {
log.info("remove........" + bno);
if(service.remove(bno))
rttr.addFlashAttribute("result", "sucess");
return "redirect:/board/list" + cri.getListLink();
}
UriComponentsBuilder로 생성된 URL은 화면에서도 유용하게 사용될 수 있는데, 주로 JavaScript를 사용할 수 없는 상황에서 링크를 처리해야 할 때 사용된다.
'Spring' 카테고리의 다른 글
| [23] REST 방식과 Ajax를 이용하는 댓글 처리 - Ajax 댓글 처리 (0) | 2019.12.30 |
|---|---|
| [22] REST 방식과 Ajax를 이용하는 댓글처리 - REST 방식으로 전환 (0) | 2019.12.27 |
| [20] 기본적인 웹 게시물 관리 - 페이징 화면 처리 (0) | 2019.12.25 |
| [19] 기본적인 웹 게시물 관리 - MyBatis와 스프링에서 페이징 처리 (0) | 2019.12.23 |
| [18] 기본적인 웹 게시물 관리 - 오라클 데이터베이스 페이징 처리 2 (0) | 2019.12.23 |