from : http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=servlet&c=r_p&n=1025300430&k=jstl&d=tb#1025300430
제목 : 당신은 JSTL을 쓰시겠습니까?
글쓴이: 이아스(iasandcb) 2002/06/29 06:40:30 조회수:2657 줄수:188
최근에 나는 모대학의 전산처에서 근무하고 있는 교직원들을 대상으로
자바 웹 프로그래밍을 가르쳤다.
자바-서블릿-JSP에까지 이른 이들에게
나는 과감하게 정식으로 나온지 채 한달도 되지 못한
JSP 표준 태그 라이브러리(이하 JSTL)를 소개하고
기존 자바 코드 기반의 스크립틀릿(scriplet. <% ~ %>)과 비교하여
JSTL의 사용법을 대조적으로 일러주었다.
"이렇게 해서 스크립트없는(script-less) JSP를 만들 수 있는 겁니다."
하지만 한 학생이 재빠르게 응수했다.
"선생님, 하지만 그냥 스크립틀릿을 써도 되는 거죠?"
JSP를, 자바 웹 개발을 하고 있는 당신이라면 이 질문에 어떻게 답하겠는가?
"물론이죠. 써도 됩니다."
나는 순간 머리속에 그런 JSP를 스크립트로 찬(script-ful) JSP라고 부르고 싶어졌다.
"그럼 한번 모두의 의견을 들어봅시다."
이렇게 해서 다양한 배경과 지식을 가지고 있는 현업의 개발자에게
scriptless와 scriptful에 대한 의견을 물어보았다.
정리해보면 대강 다음과 같다.
1. 완전히 JSTL만 쓴다. 순수 scriptless 파.(이것이 바로 JSP 2 스타일이다.)
2. 완전히 스크립틀릿만 쓴다. 또한 순수 scriptful 파.(이것이 바로 JSP 1 스타일이다.)
3. 간단히 적용할 수 있는 곳에는 JSTL을, 복잡한 로직에는 스크립틀릿을 쓴다.
(simple JSTL, complext scriptlet - 매우 현실적으로 들린다.)
4. 가능하면 JSTL을, 하지만 안된다면 스크립틀릿을 쓴다.
(JSTL as much as possible, but scriptlet also used)
5. 편한대로 섞어쓴다. (mix)
6. 디자이너와 개발자의 업무가 분리되어있다면 JSP 2 스타일을 쓰겠지만,
그렇지 않다면(즉 개발자가 페이지 저작 업무를 전담한다면)
JSP 1 스타일을 쓴다.
어느것하나 일리 없는 의견이 없다. 그런데 어째서 이렇게 다양한 의견의 스펙트럼이
나오는 것일까?
이런 정황을 깊게 이해하기위해서는 어째서 JSTL이, 아니 어째서 커스텀 태그의 개념이
등장했는지를 살펴보아야할 것이다.
1999년 여름 처음 선을 보인 이후로, 많은 자바 개발자들이 혹은
동적 웹 페이지 저작자(author)들이 JSP를 써왔다. 차차 자바 코드와 HTML 태그가
혼재하면서 많은 관련자들이 JSP 코드 표기법(code convention)에 대한 회의를
품기 시작했다.
"저는 JSP 프로젝트를 하고 있습니다. 어디 좋은 코드 표기법이 없을까요?"
이런 질문은 JSP관련 포럼에 가보면 숱하게 있고도 무척 진지한 것이다.
물론 답변도 있고 대안도 있지만, 뭔가 시원하게 확 풀어주는 "멋진 표준"이 없었다.
이런 분위기에는 JSP기술의 제안자인 썬조차도 이렇다할 JSP 표준 표기법을
선전하지 못하고 있다는 배경도 깔려있지 않을까.
그러던것이 해법은 아주 엉뚱한 곳에서 튀어나왔다.
"이제 JSP안에서는 자바 코드 대신에 커스텀 태그를 쓰시오.
그러면 JSP안에는 온통 태그이니 표기법 혼란도 없을 터..."
그렇다. JSP안을 판치는 반복문, 조건문은 이런 모양새를 취하고 있었다.
<TR>
<% if (a.equals("b")) { %>
<TD> 온갖 디자인....
<% } else { %>
<TD> 또 온갖 다자인....
<% } %>
...
이런 상황에서 과연 어디에 들여쓰기를 맞춰야할지 난감할 뿐더러,
어느쪽으로 맞추어도 보기에 눈이 어지러운 것은 피할 수가 없다.
왜? 본질적으로 HTML태그와 자바 코드는 이질적이기 때문이다.
그러나 이를 JSTL로 표현하면 상황은 달라진다.
<TR>
<c:if test="${a == 'b'}">
<TD>
...
</TD>
</c:if>
</TR>
JSP코드의 가독성과 동시에, 자바 코드(그리고 그 표기법)을 모르는 사람도
직관적으로 HTML적인 들여쓰기를 통해 형식과 내용을 동시에 손쉽게 파악하는 것이
가능해진 셈이다.
하지만 이것만으로는 학생들이게 JSTL의 존재가치를 확실히 해주기에는 부족하다.
6번째 의견으로 돌아가, 디자이너와 개발자가 분업을 한다고 가정하자.
hello.jsp에 매겨변수 name으로 ias라는 값을 주면 "안녕", 아니면 "안녕하세요."
를 찍도록 디자인해서 코드를 짰다고 하자. 만약 개발자가 스크립틀릿을 썼다면
<%
if (request.getParameter("name").equals("ias"))
{
out.println("안녕");
}
else
{
out.println("안녕하세요.");
}
%>
개발자에게는 지극히 단순하고 당연한 논리겠지만, 이미 프레젠테이션 로직이
자바코드속으로 들어가면서 디자이너와는 생이별을 고한 것이다.
그런데 상황은 이 이후이다. 만약 어느날 개발자가 몸이 아파 잠수를 타고 있는데,
"안녕"을 "안녕하세요"로, "안녕하세요"를 "안녕하십니까"로 바꾸라는 일이 떨어진다면,
디자이어는 아무 생각없이 hello.jsp를 드림위버등의 웹디자인툴로 열어보고는
하염없이 문구들을 찾아헤맬 것이다. 하다하도 겨우 개발자와 연락이 되면,
"소스 코드를 보세요."
그동안 허비했던 시간도 시간이지만, 일순 성질이 날 것이다.
자기는 분명히 HTML에 디자인해주었건만, 마음대로 프로그램 코드에 집어넣다니...
물론 현실적으로 HTML 소스 코드에 민감한 민완 디자이너에게는 별 상관없겠지만.
만약 위의 상황을 JSTL로 해결한다면 어떨까?
<c:if test="${param.name == "ias"}">
안녕
</c:if>
<c:if test="${param.name != "ias"}">
안녕하세요
</c:if>
위의 JSP코드는 디자인툴로 보아도 <c>태그로 표시되고 안녕과 안녕하세요도
그대로 나온다. 바로 고쳐도 되겠지만, 소스코드를 봐도 의미는 상큼하다.
프로그래밍을 전혀 모른다고 해도, 기본적인 영어와 수학의 아이디어만으로
XML적인 표현법이 인간에게 친절히 컴퓨터의 세계를 안내하는 것이다.
결국 JSTL을 적용하여 JSP개발자 자신도 코드 가독성을 얻고,
HTML디자이너도 JSP내의 프레젠테이션 레이어에 대한 접근성을 얻는다...
는 꿩먹고 알먹는 식의 발상이 발전하면, 3번 의견의 경지로 올라간다.
그리고 점차 익숙해지면 5번 의견으로, 그리고 그 효율을 절감하면
4번으로, 그리고 마지막으로 JSP 2.0 궁극의 달성점인 1번으로 가는 것이다.
그럼에도 불구하고, 2번 의견은 전혀 위협을 느끼지 않는다.
실제 업무에서는 민첩한 원형구축(rapid prototyping)을 통해 신속한 기능구현을
해야할 때가 잦기 때문이다. 특히 아직 낮선 JSTL은 위급한 순간에는
잘 나오지 않을 수도 있다. 그만큼 몸에 익은 기술들을 무의식적으로 쓰는
개발자의 본능때문이기도 하지만.
JSP 1 스타일이 기존의 JSP 개발자의 민첩한 원형작성용이라면
이런 상상은 어떨까?
"2003년 봄. JSP 2 스타일을 지원하는 웹 컨테이너가 대세가 되고
서점에는 "자바를 전~혀~ 몰라도 짤 수 있는 JSP"류의 책이 나오며
교육센터에서는 JSP 2 스타일 강좌(만) 개설..."
이런 환경에서 배출된 JSPer(JSP개발자)라면 어쩌면 원형조차도 JSTL로 만들어버리지
않을까? 이런 생각은 Early Adopter JSTL의 저자가 SQL관련 JSTL 태그의 존재의미를
설명하는 구절에서도 살짝 베어난다.
이번에 아파치가 배포하고 있는 JSTL구현체에는 독특한 선택지가 있다.
CORE LIBRARY
EL: <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
RT: <%@ taglib prefix="c_rt" uri="http://java.sun.com/jstl/core_rt" %>
JSTL 핵심 라이브러리를 쓰기 위한 taglib 지시자에 c와 c_rt라는 두가지 접두사가 있다.
과연 c는 뭐고 c_rt는 뭘까?
JSTL의 스펙 문서를 보면 수식어(Expression Language)에 대한 내용이 상당히 앞에 나온다.
아무리 JSTL을 쓴다고 해도 변수의 값을 다루는 데 있어서는 수식이 필수,
이것을 자바 코드 스타일로 한다면 여전히 JSP페이지에는 자바 코드가 남아있는 셈이다.
그래서 자바 언어와는 다른 스크립트 언어(ECMAScript와 XPath의 융합)로
EL을 형성해서 JSP안의 수식표현을 유도하고 있다.
그리고 이것이 바로 c접두사이다.
그렇다면 c_rt는? 여전히 EL에 익숙하지 않은 개발자들을 위해
기존의 스크립트방식(이것을 rtexprvalues라고 부른다)도 허용한다.
그 예가 아파치 스탠다드 태그립에 들어있는 예제인
Collaboration.jsp로서 다음과 같은 코드가 들어있다.
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
<%@ taglib prefix="jr" uri="http://java.sun.com/jstl/core_rt" %>
...
<table>
<c:forEach var="customer" items="${customers}" varStatus="status">
<tr>
<jsp:useBean type="javax.servlet.jsp.jstl.core.LoopTagStatus" id="status"/>
<jr:choose>
<jr:when test="<%= status.getCount() % 2 == 1 %>">
<td bgcolor="#FFFF66">
</jr:when>
<jr:otherwise>
<td bgcolor="#99FFCC">
</jr:otherwise>
</jr:choose>
<c:out value="${customer}"/></td>
</tr>
</c:forEach>
</table>
${...}형식이 EL(elexprvalues)방식이고, <%= ... %>이 여지것 잘 보아왔던 RT방식이다.
고로, JSTL은 급진적인 EL기반의 JSP 2 스타일과 더불어,
과도기적인 RT 기반의 JSP 1 스타일도 허용하는 셈이다.
과연 JSTL을 사람들이 쓸 것인지. 너무 앞서면 절멸하는 경우는 흔히 보았지만,
JSTL이 너무 앞섰다고 생각하는 사람은 그닥 많지 않을 것 같다.
오히려 늦었다면 늦었고, 어쩌면 더 큰 장애물은 새로운 것은 웬지 귀찮은
개발자 자신들일지도 모른다.
정작 자신들의 필요에 의해 만들었음에도.
그 필요성을 전혀 절감하지 않은 신규 JSP 저작 인력들에 의해
JSP 2 스타일이 퍼질지도 모른다는 생각을 하면
참 세상은 아이러니 만땅이구나 하며
고개를 모니터로 돌리게 된다.
과연 학생들이 어떻게 JSTL에 반응하여 게시판들을 만들지 지금부터 궁금하다.
이아스의 자바 정보 섹션-스타벅스
http://iasandcb.hihome.com/Korean/starbucks
ias&cb
제목 : Re: 능력과 관련있는 문제겠지요...
글쓴이: 손님(guest) 2002/06/30 05:40:46 조회수:539 줄수:17
이 문제는 웹 프로그래밍 뿐만 아니라 보통의 프로그램에서도 같은 현상입니다.
능력이 있는 선수는 재 사용이 가능한 로직, 컴포넌트, 함수등을 만들어 내면서
작업을 하고 무능한 놈은 그렇지 않지요. 이 놈들은 모듈화 하라면 재 사용이 불가능한
복잡성만 증가 시키는 함수를 양산하게 됩니다.
웹도 같다고 생각합니다. JSTL이 나오게 된 이유나 이걸 써서 이득을 볼 수 있는
사람들은 문제를 정확히 이해하고 있는 사람들입니다. 어떤 프로그래밍 언어가 쉽
다라고 할 때는 접근이 용이하다는 것을 의미하는데 웹의 경우 스크립트 언어가
대부분 그렇습니다. 그러나 질 좋은 코드는 거기서보다는 다른쪽 컴포넌트 베이스에서
잘 나옵니다.
요는 개발자의 능력에 따라 효과는 다를 것이라는 말입니다. 그리고 관리자의
마인드도 영향이 있겠지요. 당장 돈이 덜 드는 하급 인력을 대량으로 써서
땜빵으로 개발을 하든가, 아니면 고급 인력을 이용해서 하든가. 보통 잘 하고
싶은데 시간이 없다고 주장하는 하급인력들도 있는데 대부분 툴 개발을(툴을
필요하면 만든다는 말입니다. JSTL같은 경우는 조금만 손을 대면 GUI RAD와 같은
툴을 만들기 쉽습니다.) 할 능력이 없는 사람들입니다.
제목 : Re: 능력과 관련있는 문제겠지요...
글쓴이: 손님(guest) 2002/07/01 14:28:00 조회수:407 줄수:44
왜 JSTL을 사용하냐고 묻는다면... ??
님께서는 능력이 있어서 사용한다고 말씀하시는 것과 비슷한 답변이시군여..
java의 TagLib라는 것이 MS .NET의 "aspx" tag과 똑같은 기능을 하는데,
누가 먼저 이런 개념을 시작했는지는 모르겠습니다..ㅡㅡ;;
하지만, 중요한건 이걸 왜 사용하는지, 이걸 사용해서 어떤 장점이 있는지,
이거보다 더 나은 방법이 있는지.. 그게 먼저 중요한건 아닌가요..?
UML이나 RUP가 좋다는 건 다 아는 사실입니다.
하지만 때로는 그런 정석적인 방법보다, 나름의 방법이 나은 경우가 많습니다.
물론 큰 프로젝이라면, 얘기는 달라지겠지만, OO 나 CBD가 아무리 좋다 해도,
투자대비 수익이 떨어진다면, 과감하게 다른 길을 택해야 겠지요..
java의 petstore와 ms.net의 petshop이라는 blue-print버전의 소스는
님께서도 보셨겠지만, 글구, ms.net의 속도가 java보다 최고 3~40배 빠르다는
얘기도 들으보셨겠지요.. 정말 ms.net의 petshop 소스를 한번 보시면
허무할 정도라는 걸 느끼실 겁니다. 패턴이란 개념은 찾아보기 힘들정도이며,
컴포넌트란 말은 허망하게까지 느끼실 정도의 ms.net petshop소스..
하지만, 님께서는 ms.net의 petshop이 java의 petstore보다 3~40여배 나은
퍼포먼스를 낸다는 말씀을 듣고, 뭘 느끼고, 어느쪽에 손을 드셨나여..?
남들이 패턴이니, 이디엄이니 하니깐, 그게 정답인줄 알고 나두 해야쥐..
JSTL로 자바코드가 전혀 없는 jsp파일을 만든들, 자바의 내부 개념을 모르는
개발자가 JSTL을 핸들링 할정도로 개발할 자신이 없다면, 그러기엔
설계와 개발에 너무 많은 시간이 소요된다면, 그만큼 수익성이 없다면
방향을 바꿔야죠..
JSTL을 사용하지 않는 사람은 능력이 없는 하급인력이 아닙니다.
하급인력, 상급인력, ^^ 무슨 드래곤볼 비디오 찍나여..?^^
아시다시피, JSTL은 JSR에서 수행되고 있는 수많은 프로젝트중 하나일뿐입니다.
님은 그 JSR에서 추천하는 모든 방법은 적용해서 개발하시나요..?
님보다 뛰어난 능력자는 어디 숨어있어도 여러 수십, 수백만명이 숨어있고,
물론, 이제 처음시작하는 사람도 많습니다. 하지만 님의 시작도 그사람과
다를게 없었습니다. 그 사람들과 님의 실력차이는 얼마나 될것 같습니까.?
대세나 주류는 항상 존재합니다. 하지만 그 주류를 안 따른다고 바보는 아닙니다.
결론은 JSTL 하나로 하급, 고급 구분하는 그런 어리석은 말씀은 삼가해주세요.
적어도 JAVA를 이용해서 Software를 개발하시는 분이시라면...
제목 : Re: 능력이 있어야 한다는 말은...
글쓴이: 손님(guest) 2002/07/02 01:21:33 조회수:168 줄수:26
제가 능력이 있으니 나는 잘난 놈이다라는 분위기로 알아 들을 줄이야...
말씀하신대로 RUP든 뭐든 좋다는 것은 알고 있고 경우에 따라 다르게 써야
한다는 것은 맞는 말씀입니다. 만약 Pet Store를 만들 더라도 한번, 한대의
기계에 향후를 생각하지 않고 만든다면 .net버전 처럼 특정한 플랫폼에, 특정한
가술에 맞추어서 만들기도 하겠지요. 그러나 이 프로그램이 계속 확장될 것이고
다양한 곳에서 돌아야 된다면 Blue Print에 가깝게 만들어야 합니다. JSTL도
마찬가지가 아닐까요? 사용자 인터페이스에서 코드를 분리해 냄으로써 얻을 수
있는 이득은 매우 큽니다. 일단 웹프로그램에 적응이 되지않은 고급 프로그래머
(제가 하급, 고급이라고 하는 것은 사람을 평가하는 것은 아닙니다. 프로그램
작성 능력에 대한 구분으로 생각해 주세요)도 금방 투입이 가능합니다. 즉, HTML
에 대해서 몰라도 된다는 것이지요.(이런 쪽으로 더 확실히 하려면 Component based
framework, like Tapestry의 도입이 더 좋습니다만...) 따라서 인력의 관리도
용이하고 인터페이스만의 변경이라면 더 싼 인력 또는 디자인에 좀 더 전문적인
인력의 사용도 가능하다는 것이지요. 만약 Scriptlet이 들어 있다면 후자는
아무래도 힘들어지고 그걸 조금이라도 한 비슷한 수준의 인력은 좀 더 비싸
집니다. Java를 사용하는 싸이트는 아니지만 처음에 싼 맛에 ASP인력을(스크립터
수준의) 대량으로 고용해서 싸이트를 운영해 오다가 싸이트가 커짐에 따라 잘못된
코드, 프로그램 구조로 인해서 점점 많은 비용으로 고생하는 곳을 알고 있습니다.
결국 인력 정리를 해서(싼 다수의 인력을 정리하고 고급 인력을 채용해서 싸이트
어플리케이션을 정리했습니다) 비용 절감을 이룬 곳도 있습니다. 말씀드리고 싶은
것은 고급, 하급으로 나누는 것이 중요한 것이 아니라(저도 고급도 아니고 배우는
것이 많은 사람의 입장입니다.) 단지 몰라서, 쓰는 대 익숙하지 않아서는 사용,
비사용의 이유가 될 수는 없다는 것입니다. 필요하다면, 그 기술을 이용해서
얻을 수 있는 이득이 확실하다면 그걸 사용할 수 있는 능력이 있어야 되고
그래서 능력에 따라서 라는 말씀을 드린 것입니다.
제목 : Re: 능력이 있어야 한다는 말은...
글쓴이: 손님(guest) 2002/07/02 02:05:32 조회수:68 줄수:12
저위의 분이 잘못 알아 들었다기 보단 님이 잘못 말한거로 보입니다.
님의 말은 제가 보기에도 그런 분위기로 들리는 군요. 두번째 쓰신거는 안그렇지만..
시간이 없어서 잘만들지 못했다는걸 하수들의 변명으로 치부하시고 계시지만 시간이 부족해도
제대로 만들수 있다는 고수는 전 아직 보지도 듣지도 못했습니다.
툴을 만들 능력이 없어서 시간네에 만들지 못한다는 말은 말도 안됩니다. 프로젝트 개발에
많은 도움을 툴이라면 이미 대부분 나와 있을겁니다. 나와 있지 않더라고 하더라도 당장
내일 모래가 마감인데 툴을 만들어서 시간이 더 단축될 경우가 얼마나 있을가요? 회사에서
그런 사람을 고용할때 그사람이 툴을 만들줄 모르는 사람이란걸 모르고 고용할까요? 당연히
그런 사람들 한테는 더많은 시간을 주어야 합니다.
물론 저도 초보자들에 의해서 많은 잘못된 코드가 나온다는 점에는 저도 동의 합니다.
그렇기 때문에 신입 사원들을 재교육시키고 더낮은 임금을 주는게 아닌지요?
제목 : Re: 능력과 관련있는 문제겠지요...
글쓴이: 손님(guest) 2002/07/02 06:51:35 조회수:160 줄수:31
본글에 처음으로 답변을 단 분의 말씀이 결코 틀린말 같지는 않군요. 몇몇 사람의
감정을 자극하는 단어들을 사용한 점은 유감입니다만, 그 뜻은 충분히 공감합니다.
프로젝트에 투입된 모든 개발자가 RAD 툴을 만들 수 있는 고급인력일 필요는 없겠지요
한명만이라도 잘 뽑아낼 수 있는 사람이 있으면 되잖습니까? 나머지 사람들은 그걸
사용할 뿐이구요. 뭐 정석대로 피라미드 구조로 인력들이 투입되었다면 좋겠다...라는
얘기지요.
나름대로 아키텍쳐에 대한 고민이 프로젝트에 꼭! 필요불가결한 것이라고 생각하는
사람의 입장에서 본다면, 저는 절대 찬성입니다. 윗분이 얘기한 것은 결코 이제 자바에
막 입문하신 분이나 '초급' 딱지를 붙이신 분들을 비하할려는 의도는 아니라고
생각합니다. 다만 자바라는 언어의 특성을 제대로 이해하지 못하는 개발자가 자바
프로젝트에 오히려 해를 끼칠 수도 있다는 거지요. 이런분들을 위해서 어떤 꽉차여진
틀이나 툴의 제공은 필수적인 것이라고 생각합니다.
그런점에서 JSTL과 같은 어떤 '틀'의 존재는 매우 환영할만합니다. '초급 프로그래머는
자바코드를 한줄도 프로젝트에 반영하지 않는다. 고로 위험성도 없다'라는 것입니다.
(JSTL도 제대로 구사하지 못하는 개발자의 자바코드를 믿을 수 있겠습니까? 귀찮을
뿐이지 어려운일은 아니지 않습니까?)
한마디 더 하자면,
경력은 많지만 자바는 잘 모르는분. 프로젝트를 진행하다가 보면 이런분들을 많이
만납니다. 경력만큼 영향력을 행사하려 하지요. 객체개념이 없는 중급이상의 개발자
(자바책이야 확실히 하나쯤 읽었겠지요. RUP도 알고, UML도 알겠지요. 경력이 있으니
모르는건 거의 없습니다. 그러나 객체개념이 없는 사람이지요)
.... 어떠십니까? 이런분이 PL이나 PM이라면? 이 사람 밑에서 자바 프로젝트를
진행해야 한다면? 등줄기에 식은땀이 흐르지 않습니까? 생각하는 것만으로도
끔찍할 겁니다.
(시간이 없으니까, 이게 편하니까라는 생각으로 쉽고 빠르게 프로젝트를 진행하는 것이
맞다고 여기는 분이 아니시라면)
이상과 현실의 갭에 대해서 얘기할 필요는 없을 것 같습니다. 여기는 자바서비스넷
아닙니까. 그게 꿈으로 끝날지라도 자바 꿈을 꿔야한다고 생각합니다.
제목 : JSTL에 대한 생각
글쓴이: 수리바다(guest) 2002/07/09 11:53:42 조회수:1033 줄수:43
www.suribada.com에서 가져온 글입니다. (앞부분의 내용은 무슨 광고 같아서 귀찮으실지도
모르지만 경험상 얘기한 거라서..)
공개게시판 NowBoard XML 버전을 만들기 전에 몇 가지 시도를 해보기로 하였습니다.
XML 파일이나 XML DB를 이용하는 것은 생소하기도 하고 자료도 많지 않은 까닭에 조금 더
시간을 두고 만들어야 한다는 판단이 작용하였습니다.
맨 먼저 현재의 EJB를 Local EJB로 바꾸면서(1.5버전에서 간편하게 하기 위해 엔티티 빈에서
업로드한 파일을 지우고 있는데 그럴려면 EJB가 로컬에 있다는 것을 가정해야만 합니다.)
그와 함께 요즘 한참 이아스님이 얘기하고 있는 이슈인 JSTL을 적용해보는 것이었습니다.
그 이후에 템플릿(아파치 프로젝트의 Velocity)를 이용하여 만드는 방법과 함께 그 이후에는
Struts 그리고 그 다음에는 Cocoon까지를 적용해보는 것입니다. 수리바다 사이트를 개편
하면서 PHP에서 템플릿을 사용하는 이점을 충분히 느꼈기 때문에 템플릿에 대한 관심이
높아져 템플릿을 이용한 게시판으로 바꾸려고 했지만 그동안 JSP로 먹고 살기도 했으니
JSP를 몰아내기가 못내 아쉬워서 이 버전까지는 JSP를 활용해보자 하고 마음을 먹었습니다.
반년전까지만 해도 책보는 건 즐기는데 스펙 보기를 돌같이 했던 제가 이제는 책보다는
스펙을 뒤져가면서 공부를 하고 있습니다. 이제 JSTL 스펙을 여기 저기 찾아보면서 JSTL판
NowBoard를 만들다가 느낀 것이 있어 간단하게 말씀드리도록 하겠습니다.
현재의 NowBoard는 Servlet centric 디자인보다는 JSP centric 디자인에 약간 치우친 경향은
있지만 로직과 디자인이 거의 분리가 되어 있습니다. 이 경우에 JSTL을 적용하려 했더니
스크립틀릿을 쓰는 것보다 더 복잡해지는 경향이 나타나고 말았습니다. 짐작으로 그러리라
생각했던, if 태그와 else 태그가 대응되는 것이 아니어서,
<c:if test="${totalCnt != '0'}">...</c:if>
에 이어 곧 바로,
<c:if test="${totalCnt == '0'}">...</c:if>
으로 다시 써야 한다는 것은 스크립틀릿에서,
<%= (totalCnt>0)?"...":"..." %>
에 비해 복잡하기도 하고, 그렇다면 앞의 경우에 디자이너가 더 직관적으로 알아볼 수
있으리라고 생각할 수 있는가 그도 아닐 것 같습니다.
그리고 JSTL은 스크립틀릿에 비해 충분한(?) 기능을 제공하지 않는 편이어서 결국
스크립틀릿을 몰아내기 위해서는 커스텀 태그를 추가로 만들어야 한다는 문제가 나타나게
됩니다. 그래서 제 머리속에 떠오른 생각은 이러합니다. "썬이 기껏 커스텀 태그를
사용하도록 하였는데 쓰는 사람은 많지 없고 해서 이를 강권(?)하는 방법으로 JSTL을 만든
것은 아닌가? JSTL을 쓰다보면 부족한 기능에 어쩔수 없이 커스텀 태그를 만들어 쓰게 될
것이다." 그럴듯한 시나리오인가요? 흐흠.
또 하나 얘기하고 싶은 것은 JSTL이 Servlet centric 디자인을 유도한다는 것입니다.
서블릿에서 생성한 Attribute을 이름만으로 참조를 할 수 있어서 JSP 소스가 깨끗해질 수
있는 면이 있습니다. 그래서 JSTL을 이용하는 것은 JSP를 이용하는 것이긴 하지만 템플릿을
이용하는 것에 더 가깝다는 느낌이 듭니다. JSP는 뷰로만 사용하고 빈과 서블릿에 로직을
넣도록 권고해 왔지만, 쉽게 지켜지지 않았던 그 권고 규칙을 조금 더 엄격하게 적용해보자고
하는 방식으로 JSP 스펙은 변화하고 있는 것일까요? 앞으로 나오게 되는 JSPer는 자바코드는
잘 몰라도 된다는 얘기가 현실이 되는 것일까요? 한번 지켜보도록 하지요.
제목 : Re: JSTL...
글쓴이: 손님(guest) 2002/07/09 14:57:12 조회수:78 줄수:26
제 개인적인 사견이란걸 전제하면서, Sun에서 JSP에 대한 로직적인 부분의 첨가를 지양하는
사실 자체가 Servlet을 중앙집중적인 디자인의 요체로 만들어버린다는 겁니다.
다른 방향으로 표현하자면, MS에서도 쉽사리 하지 못했던 디자이너나 HTML Coder에 대한
접근성을 강화하기 위한 방향으로 보여지는데, 개발에 대한 역할분류에 있어서는 바람직한
현상으로 봅니다.
자바 개발자에게는 순수한 자바 개발에 더욱 매진하는게 바람직하고, 비전문 분야인 디자인과
HTML코딩에 대해서는 그에 상응하는 전문가에게 보다 쉽게 일임할 수 있는 길을 열어주려는
것이 아닐지...
솔직히, 순수 자바 개발자에게 뷰에서의 수작업(?!)은 지나친 초과근무에 비해 영양가가
떨어지는 퀄리티를 보여주는 행위가 아닐까 싶습니다. 자바개발 이외의 작업에 대한 추가적인
지식과 감각이 필요한, 좀 무대뽀식 다중역할론을 강조하는 SI개발현실에선 어쩔수 없는 행태로
보이지만, 분명히 이런 JSP의 역할축소는 다소 의미있는 정책이라고 보기에 충분합니다.
단지, 아쉬운 점이라면 디자이너나 HTML 코더들이 그들의 작업에 JSP를 보다 쉽게 다스릴수
있는 도구가 없다는 점이 무엇보다 JSP의 역할론에 무게를 받쳐주지 못한다는 안타까운
현실이죠.
그런 의미에서 JSTL은 반가운 존재라고 보여집니다. 스크립틀릿 보단 JSTL이 자유스러움은
떨어질지 몰라도 어느정도 규격화되고 정형화된 틀을 갖추었다는 것이, 앞으로 이를 부가하는
디자인 툴이 만들어질지...
누가 알겠습니까? JSP 웹개발을 해오던 개발자들이 자바 이외의 요소에 흔들리며 힘들어하던
모습을 많이 보았던 저에게는 앞으로 좋은 방향으로 이어지길 기대해보고 있습니다.
제목 : Re: JSTL 에 대한 생각
글쓴이: 허광남(heogn) 2002/07/09 23:18:08 조회수:159 줄수:26
<c:if> else는
<c:choose>
<c:when test="">
</c:when>
<c:when test="">
</c:when>
<c:otherwise>
</c:otherwise>
</c:choose>
로 구현하시면 될 것입니다.
JSTL spec 5.3
저도 여러가지 적용을 해보려 하는데, Custom tag 를 만드는 것이 그리 녹녹하지 않더군요.
jsp 에서 선언된 변수와 값을 공유하기 어렵고, 생성된 servlet 소스를 보니
jsp 로 구현했을 때보다 적어도 3~4배는 길어지는 것 같습니다.
사소한 것 하나하나가 다 만들어져야 한다는 것이 아직도 갈 길이 멀다라는 느낌이 들고,
반면에 잘 만든 tag 하나가 여러 사람들을 편하게 할 것 같다는 생각도 듭니다.
그런대로 CharacterSet 에 대한 지원은 잘 되는 것 같았습니다.
jdbc 2.0 을 사용한 sql Action 도 맘에 들고요.
Tomcat4.0.4 에 JSTL jar 파일들을 WEB-INF/lib 에 놓았을 경우 WEB-INF/classes 의
서블릿과 빈의 패키지들이 먹통이 되는 문제 때문에 일단 잠시 멈춰있습니다.
jwsdp 에서는 잘 되는 것 같던데요.
---------------------------------
http://okjsp.pe.kr
제목 : Re: JSTL만으로는 부족..Struts같은 Framework을 이용애야한다.
글쓴이: 자바지기(guest) 2002/07/10 01:20:34 조회수:586 줄수:21
JSTL을 이용할 경우 Scriptlet보다 더 코드가 복잡해 진다고 했는데..
그건 JSP에서 너무나 많은 일을 하려고 하기 때문입니다.
즉 MVC에 근거해서 View에서 너무 많은 일을 JSTL을 이용해서 처리하려고
하기 때문이라고 생각합니다.
따라서 정말 Data와 View의 분리가 이루어 지고..
JSTL을 JSTL답게(물론 Struts에도 Tag제공한다.) 쓰려면 Struts같은
Framework을 이용하여 Model2 방식으로 개발을 해야
제대로 된 개발이라고 생각합니다.
Struts적용과 더불어 ..JDO같은(Castor, Torque, Expresso등)
Persistence Layer를 Model로 이용하여 개발을 한다면..MVC layer분리가
정확하게 될거라 생각합니다.
또한 이와같은 Framework을 사용할 경우 자연스럽게 OOP적으로 개발을 할 수 있게
되며, Architecture 설계에 대한 개념도 서서히 다가올거라 생각합니다.
아무쪼록 좋은 개발이 되기를..
제목 : Re: JSTL만드로 프로젝트를 수행해 봤습니다.
글쓴이: 손님(guest) 2002/08/03 02:59:36 조회수:670 줄수:16
JSTL만으로 저희 회사에서 몇몇 프로젝트를 수행하고 운영해 봤습니다.
현재 저희가 만든 몇몇 공공기관은 이러한 태그라이브러리로 된 프로그램이 돌고 있습니다.
그리고 태그라이브러리도 왠만한 프로젝트를 수행할 만큼 만들어 놓았고요.
개발 수행시간이 매우 짧아지더군요.
하지만..
페이지를 구성하는 태그들의 인스턴스가 많아지면서 (입력이나 출력 항목이 많은 경우
더더욱) 문제가 발생하기 시작하고 속도도 많이 떨어집니다. 그래서 컴파일된 JAVA파일을
보니 장난 아니더만요.
결국 현재는 MVC모델로 하여 Display 부분만 부분적으로 커스텀 태그를 사용 하게 되었습니다.
어쩔수 없이요...
위에 쓰신 지기님의 말씀처럼 Struts나 이와같은 프레임웍과 같이 부분적으로 사용하는
것이 좋을듯 합니다.
또한...
<% %>가 편한곳은 부분적으로 사용하도록 하고 있습니다.
억지로 다 태그라이브러리 사용하려고 하면 더 복잡하고 골치아파지기도 하는것 같더라구요.
제목 : Re: 무능력, 죄인?
글쓴이: 무능력(guest) 2003/03/03 08:50:57 조회수:354 줄수:32
좋은 내용들에 약간의 아쉬움.
전 나이 많고 늦게 프로그래밍을 시작한 사람입니다.
이 바닥에선 무능력자로 낙오자로 살고 있습니다.
근데 왜 하냐구요?
나이 먹어보세요. 자신의 뜻과 상관없이 책임져야 할 일들도 생길테니..
전 나이에 상관없이 실력있는 개발자들을 보면 존경스럽기까지 합니다.
모든 일에서 프로는 아름다우니까요.
하지만 아쉬운 점도 참 많습니다.
이 바닥에 오니 사람들이 능력을 가지고 사람의 인격까지 저울질 하는 경향이 있더군요.
현 자본사회의 주 경향이기도 하지만 특히 전산을 하는 사람들이 심한 경향이 있습니다.
기술이 곧 생존이기 때문이겠지요?
하지만 능력이나 기술이 인격은 아닙니다.
돈을 더 잘 벌 수는 있지만 더 훌륭한 사람이거나 더 훌륭한 삶을 산다고 할 수는 없죠.
또한 능력이 없는 사람들은 그 만큼 적은 돈을 받고 일합니다.
능력이 있는 사람들이 그 돈 받고 일할까요?
그리고 한가지 일에서 능력이 없는 사람이라고 다른 일에서도 능력이 없을까요?
능력이 없는 사람은 나쁜 사람일까요?
아니란거 다 아시죠?
그럼 자신보다 능력이 없다고 타인을 질타해선 안되죠?
따뜻한 조언을 해줘야 옳을 것입니다.
다들 기술은 좋은데 함께 사는 법에 대해선 고민을 안하는 것 같아서 떠들어 봤습니다.
내가 좀 더 능력이 있다고 남을 무시하진 않았나 한번 고민해보세요.
특히 일찍 성공했다고 자부하는 사람들은..
제목 : Re: 저도 동감 입니다.
글쓴이: 손님(guest) 2003/03/03 13:22:12 조회수:54 줄수:17
우리 나라에서는 항상 선진 기술
경쟁력있는 인재 양성
위의 구호를 외칩니다.
하지만 결국이들 중 많은 사람들이 도둑질을 합니다.
주가 조작, 부당 내부거래, 과대 IR
진정한 기술 자라면, 작든 크든 자기일에 자부심을 느끼고 책임을
가지는 사람이어야 겠죠.
기술과 지위에따라 사람에 대한 잣대가 달라지는 이라면,
스스로의 일에대한 자부심 또한 없는 사람이겠죠.
의사는 아픈 사람 고치라고 하나님이 주신 능력이고,
변호사는 억울한 사람 변호하라고 하나님이 주신 능력이고,
공직자는 시민들을 위해서 대신 일하면서 봉사하라고 하나님이 주신 능력이고,
기술자는 소비자를 위해서, 좋은 제품을 만들라고 주신 하나님이 주신 능력입니다.
다 남을 위해서 같이 잘 살라고 주신 능력이지,
잘 난척하라고 주신 능력이 아닌 거 같네요.
제목 : Re: 무능력과 죄인에 관해
글쓴이: 손님(guest) 2003/03/04 23:31:19 조회수:108 줄수:18
정말 인간적으로 사람을 미워하진 않습니다.
언제나 보면 빵집같은 옆집 아저씨요 피씨방 주인아저씨 같은 그들을
콩한쪽이라도 나눠먹으며 정답게 지내다가도
막상 개발 업무에 있어서는 그들이 전체 혹은 내 개인의 소스의
Design을 갉아 먹고 있다는 사실을 알았을때(정작 그들은 그사실 조차 모르고 있을때)
괴로움이 앞섭니다. 세계가 너무도 다릅니다. 접점을 찾을 수가 없습니다.
어떻게든 이해시키려 노력도 해봤습니다.
그들은 그렇게 프로젝트를 갉아먹고 결국엔 본인도 지쳐 떠나갑니다.
남은이들은 그가 일했던 만큼의 기간을 다시 메꿔나갑니다.
제목 : Re: (윗윗글 손님)저도...너무 치우 친 생각을 한거 같네요.
글쓴이: 손님(guest) 2003/03/05 02:40:08 조회수:69 줄수:11
저도 너무 치우친 생각을 한거 같네요.
능력있는 사람은 능력 있는 사람을 배려해주고.
능력 없는 사람은 스스로, 물러 날 줄 알아야겠죠.
그렇지 않다면, 능력있는 사람의 욕심과 같은 욕심 이겠죠.
스스로의 능력 없음을 모른다면, 그것도 능력 있는 사람의 오만함과 같겟죠...
우리의 욕심과 자존심은 능력있는 사람이나, 능력 없는 사람이나 같은거 같네요.
그렇다면, 우리의 주제는 능력 있는 사람의 오만함과, 능력없는 사람의 무능력함이
아니라, 우리의 욕심과 자존심으로 옮겨 가야 할것 같네요...
제 성급한 생각 죄송합니다.
제목 : Re: 이 글들은 이곳 카테고리에 적합하지 않은것 같네요
글쓴이: 손님(guest) 2003/03/05 04:23:11 조회수:57 줄수:2
그렇죠?
제목 : Re: jstl은 무능력자를 위한 것일 수도 있어요
글쓴이: 무능력(guest) 2003/03/10 17:54:49 조회수:321 줄수:34
짧게 말해 JSTL은 무능력자를 위한 것이며
무능력자가 많이 보고 많이 사용할 것이라고 생각합니다.
첫번째 글을 올리신 이아스님의 글 하단을 보면 아이러니하게도 새로 시작하는
jsper가 jstl을 보급하게 될지도 모른다고 하셨는데 동감합니다.
솔직히 모든 '재사용성'을 위한 기술들은 초급자를 위한 것이라고 생각합니다.
고급기술자들이 하기 귀찮아지는 것들을 쉽게 만들어 초급자들에게
일을 나누어 주는 것이죠.
만약 윗글처럼 초급자들이 고급자들이 만든 디자인을 엉망으로 만든다면
그건 원래 디자인이 엉망인거 아닌가요?
초급자에 의한 전체의 틀에 대한 손상을 방지하고 초급자가 고급지식이 없어도
개발을 용이하도록 하게 해주는 것이 훌륭한 디자인 아닌가요?
JSTL은 표현을 위한 언어지 내부의 비지니스 로직을 만들라고 있는건 아닌 것 같네요.
그럼 저~윗글에서 말한 무능력한 초급자들이 쓰는게 훨씬 효과를 볼거라 생각 안하세요?
제 생각엔 프레임워크까지 디자인하시는 분들이 view page에 까지 관여할 필요는
없다고 생각됩니다.( 아 물론 여기서의 관여란 전체적인 것을 말하는 것이
아니라는 것은 아시겠죠..)
다시한번 강조하지만 진짜 고수는 하수를 욕하거나 무시하지 않습니다.
그들도 고용된 사람들일뿐입니다.
잘못 기용한 이들이 바보인거지.
그리고 프로젝은 누구의 것이 아닙니다.
또 한가지 개발은 SI만 있는 줄 아는데. SM도 있습니다.
물론 여긴 SI프로젝 경험을 공유하는 곳이지만
너무 SI적인 시각으로 초급자들을 몰아세우지 마세요. 제발.
첨에 초급자 아니었던 놈있으면 나와보라고 하세요.
(위에 놈이란 단어가 있어 나도 써봤음)
제목 : Re: jstl은 무능력자를 위한 것일 수도 있어요
글쓴이: 손님(guest) 2003/04/15 01:44:19 조회수:524 줄수:11
무능력 님의 말씀에 공감합니다.
상급개발자가 framework 를 잘 만들어 놓는다면
하급자가 용이하게 사용할 수 있고, 또 그 소스를 보고
배워나가는 게 이 동네 흐름 아닌가요?
하급자가 framework 를 어줍잖게 고쳐놓는다면 그 또한 문제겠지만
framework를 하급자가 손대야 할 정도라면 그 framework 는 이미 framework라고
불려질 수 없다고 봅니다.
다시 말해 '재사용성'으로의 가치가 없다는 뜻이겠지요
제목 : Re: jsper ?
글쓴이: 곽승준(jsper) 2003/04/16 01:41:05 조회수:144 줄수:2
jsper 입니다.....
제가 뭘...? ^^
|
▒ 03.WebComponent (14) 