irt 커스텀 태그 클래스 분석: ContainsTag에 대하여

아래는 ContainsTag클래스의 첫부분이다. 

여기서 말하는 copyId, id, key중에서 id는 필수값이다(커스텀 태그 클래스 문서 보면 알수 있고 클래스 파일의 윗부분을 보면 M이라고 표시되어 있음). 따라서 id는 아래와 같이 jsp문서에서 커스텀 태그를 만들시에 기본적으로 제공되어야 한다.

위의 코드에서 id, key는 기본적으로 jsp문서에서 커스텀 태그에서 제공되는(위그림)id와 key값을 의미한다. 

또한

여기서의 pageContext.findAttribute는 서블릿에서보내온 데이터를 검색하는 것이다. 즉 id="request" 라고 jsp문서에서 커스텀 태그를 작성시 속성으로 주었으므로 servlet에서 데이터를 보낼 때도 반드시 그 객체의 이름은 아래 그림의 파란색처럼 request여야만하는 것이다. 반드시

Servlet파일에 있는 코드. 파란색의 "request"라는 이름의 객체로 request2데이터를 보내고 있다.

여기서 잠깐 왜 ContainsTag 커스텀 태그에서는 서블릿에서 데이터를 보낼 때 아래 그림과 같은 setAttribute형식(45라인)이 아닌 맵을 통해 데이터를 put(47,48라인)해야만 하는 것인가? ==>> 그럴 필요없다!! 맵이 아닌 setAttribute형식을 사용하더라도 보내는 데이터의 이름을 "request"로 하면 JSP쪽에서는 정상적으로 읽을 수 있다. 

 

45라인과 같이 맵을 쓰지 않고도 데이터를 전송하고 이를 JSP쪽에서 성공적으로 읽을 수 있다. 다만 47~49라인과 같이 맵을 생성하고 그안에 데이터를 put하면 보는 것과 같이 key, value형태로 값의 종류를 하나더 늘려 전송할 수 있는 것이다. 즉, 전송할 수 있는 값이 늘어나는 것이다.

 

맵을 사용하지 않고서는 위와 같이 단일 데이터(Object=user)만 Object객체의 값으로 나온다. (컨솔에 나온값으로

코드의 결과이다

)

반면 맵사용시 아래와 같은 결과를 얻을 수 있다.

다만!!! ContainsTag커스텀 태그 클래스를 보면 아래와 같은 코드가 나오는데 servlet으로 부터 전송받은 데이터가 단순 값이 아닌 맵 형태의 데이터여야만 78라인으로 들어가고 그후 Servlet으로 부터 받은 맵데이터중 JSP에서 제공된 key와 같은 key가 있는지를 살피게 된다. 만약 있다면 82라인에서 보듯이 true가 되어 EVAL_BODY_INCLUDE. 즉, 커스텀 태그안의 body부분인 

<p>User parameter is present in the request.</p> 코드가 실행되는 것이다. 반면 맵형태의 데이터가 오지 않으면 83라인으로 가서 커스텀 태그 안의 내용을 SKIP하게 된다(return SKIP_BODY)

JSP파일에 쓰인 커스텀 태그

==============================================================================

 

별개로, 아래의 doStartTag에 들어갈 때 id, key등은 이미 JSP파일에서 에서 커스텀 태그의 속성으로 받았던 id, key값이 들어가게 된다.