오늘날 서블릿을 사용하는 모든 개발자는 Sun Microsystems가 개발한 웹 기술인 JSP를 알고 있으며 서블릿 기술을 홍보하고 구축하기 위해 많은 노력을 기울였습니다. JSP는 서블릿에서 HTML 코드를 분리하여 웹 애플리케이션 개발 및 페이지 유지 관리 속도를 높입니다. 실제로 Sun이 발행한 공식 "애플리케이션 개발 모델" 문서는 더 나아가 "JSP 기술은 표준으로 간주되어야 하며 대부분의 경우 서블릿은 보충으로 간주될 수 있습니다."라고 합니다. 의견 버전을 들어보세요).
이 기사의 목적은 JSP를 다른 서블릿 기반 기술인 템플릿 엔진과 비교하여 이 진술의 타당성에 대한 평가를 듣는 것입니다.
서블릿을 직접 사용할 때의 문제점
처음에는 서블릿이 발명되었고 전 세계가 그 우수성을 보았습니다. 서블릿 기반의 동적 웹 페이지는 빠르게 실행될 수 있고, 여러 서버 간에 쉽게 전송될 수 있으며, 백엔드 데이터베이스와 완벽하게 통합될 수 있습니다. 서블릿은 웹 서버에 선호되는 플랫폼으로 널리 받아들여지고 있습니다.
그러나 일반적으로 단순하게 구현되는 HTML 코드에서는 이제 프로그래머가 HTML의 각 라인마다 out.println()을 호출해야 하는데, 이는 실제 서블릿 애플리케이션에서 심각한 문제가 되었습니다. HTML 콘텐츠는 코드를 통해 구현되어야 하는데, 이는 대규모 HTML 페이지의 경우 지루하고 시간이 많이 걸리는 작업입니다. 또한 웹 콘텐츠를 담당하는 사람들은 모든 업데이트를 수행하기 위해 개발자를 고용해야 했습니다. 이러한 이유로 사람들은 더 나은 솔루션을 찾고 있습니다.
JSP가 도착했습니다!
JSP 0.90이 등장했습니다. 이 기술에서는 Java 코드를 HTML 파일에 포함시키고 서버는 자동으로 페이지에 대한 서블릿을 생성합니다. JSP는 서블릿을 작성하는 쉬운 방법으로 간주됩니다. 모든 HTML은 out.println()을 호출하지 않고도 직접 얻을 수 있으며, 페이지 콘텐츠 담당자는 Java 코드가 손상될 위험 없이 HTML을 직접 수정할 수 있습니다.
그러나 페이지 아티스트와 개발자가 동일한 파일에 대해 작업하는 것은 이상적이지 않았으며 Java를 HTML에 포함시키는 것은 HTML을 Java에 포함시키는 것만큼 당황스러운 일이었습니다. 여전히 엉망인 코드를 읽는 것은 어렵습니다.
그 결과 사람들은 jsp를 사용하는 데 성숙해졌고 JavaBeans를 더 많이 사용하게 되었습니다. Bean에는 jsp에 필요한 비즈니스 로직 코드가 포함되어 있습니다. JSP의 코드 대부분은 빈에 넣을 수 있으며 빈 호출을 위한 아주 적은 양의 마크업만 남깁니다.
최근 사람들은 이런 방식의 JSP 페이지가 정말 뷰와 같다고 생각하기 시작했습니다. 클라이언트 요청 결과를 표시하는 데 사용되는 구성 요소가 됩니다. 그러면 사람들은 뷰에 직접 요청을 보내면 어떨까라고 생각할 것입니다. 대상 뷰가 요청에 적합하지 않으면 어떻게 되나요? 결국 많은 요청에는 결과 보기를 얻을 수 있는 가능성이 여러 가지 있습니다. 예를 들어 동일한 요청으로 인해 성공적인 페이지, 데이터베이스 예외 오류 보고서 또는 누락된 매개변수에 대한 오류 보고서가 생성될 수 있습니다. 동일한 요청으로 클라이언트의 로케일에 따라 영어 페이지 또는 스페인어 페이지가 생성될 수 있습니다. 클라이언트가 요청을 뷰에 직접 보내야 하는 이유는 무엇입니까? 클라이언트가 일부 일반 서버 구성 요소에 요청을 보내고 JSP 뷰가 반환하는 것을 서버가 결정하도록 하면 안되는 이유는 무엇
입니까
?Model 2" 디자인은 JSP 0.92에 정의된 모델-뷰-컨트롤러 기반 모델입니다. 이 디자인에서는 요청이 비즈니스 로직을 수행하고 표시할 유사한 데이터 "모델"을 생성하는 서블릿 컨트롤러로 전송됩니다. 그런 다음 이 데이터는 표시를 위해 내부적으로 JSP "뷰"로 전송되어 JSP 페이지를 일반 임베디드 JavaBean처럼 보이게 만듭니다. 제어를 담당하는 서블릿의 내부 로직에 따라 적절한 JSP 페이지를 선택하여 표시할 수 있습니다. 이러한 방식으로 JSP 파일은 아름다운 템플릿 보기가 됩니다. 이것은 또 다른 개발이며 오늘날까지 다른 개발자들로부터 칭찬을 받고 있습니다.
템플릿 엔진
을 사용하여 범용 JSP를 대체하면 후속 디자인이 더 간단해지고 구문이 더 간단해지며 오류 메시지를 더 쉽게 읽을 수 있습니다. , 도구가 더욱 사용자 친화적이 될 것입니다. 여러 회사에서 이러한 엔진을 만들었으며 가장 유명한 회사는 아마도 WebMacro( http://webmacro.org , Semiotek의)일 것이며 해당 엔진은 무료입니다.
개발자는 JSP를 대체할 템플릿 엔진을 선택하는 것이 jsp의 일부 단점이기도 한 기술적 이점을 제공한다는 점을 이해해야 합니다.
문제 #1: Java 코드가 너무 템플릿화되어
있음에도 불구하고 JSP는 여전히 Java를 추가하려고 시도합니다. 웹페이지에 코드를 추가합니다. 이는 한때 Java가 했던 것과 다소 비슷합니다. 템플릿 엔진은 jsp에서 하위 수준 소스 코드를 제거하여 이를 단순화했습니다. 템플릿 엔진은 더 나은 디자인을 구현합니다.
질문 #2: Java 코드 필요
JSP 페이지에 일부 Java 코드를 작성해야 합니다. 예를 들어 페이지가 현재 웹 애플리케이션의 루트 컨텍스트를 결정하고 해당 홈 페이지로 연결된다고 가정합니다.
JSP에서는 다음 Java 코드를 사용하는 것이 가장 좋습니다:
홈 페이지
Java 코드를 피하고
property="contextPath"/>/index.html">HomePage
템플릿 엔진을 사용하면 Java 코드와 보기 흉한 구문이 없습니다. 동일한 요구 사항 하에 WebMacro에서 작성하는 방법은 다음과 같습니다.
WebMacro에서 ContextPath는 Perl과 유사한 구문을 사용하여 $Request 변수의 속성으로 사용됩니다. 다른 템플릿 엔진은 다른 구문 유형을 사용합니다.
또 다른 예를 살펴보면 고급 "뷰"가 사용자의 기본 색상 구성을 기록하기 위해 쿠키를 설정해야 한다고 가정합니다. 이 작업은 서블릿 컨트롤러가 아닌 뷰에 의해 완료될 가능성이 높습니다. JSP에는 다음과 같은 Java 코드가 있어야 합니다.
<% Cookie c = new Cookie("colorscheme", "blue") %>
WebMacro에는 Java 코드가 없습니다.
#set $Cookie.colorscheme =
원래 쿠키의 색상 구성을 검색하려는 경우 마지막 이온으로
"파란색"을
사용합니다.JSP의 경우, 도움이 되는 해당 도구 클래스를 생각할 수 있습니다. 왜냐하면 getCookies()를 사용하여 이러한 하위 수준 작업을 직접 수행하는 것은 터무니없고 어려워지기 때문입니다. JSP에서:
<% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %>
WebMacro에서는 도구 클래스가 필요하지 않습니다. 일반적으로 $Cookie.colorscheme.Value입니다. JSP를 작성하는 그래픽 아티스트의 경우 어떤 구문을 배우기 더 쉽습니까?
JSP 1.1은 임의의 HTML과 유사한 태그가 JSP 페이지의 백그라운드에서 Java 코드를 실행할 수 있도록 허용하는 사용자 정의 태그를 도입했습니다. 이것은 어느 정도 가치가 있지만 널리 알려져 있고 모든 기능을 갖춘 무료로 사용할 수 있는 표준화된 태그 라이브러리가 있는 경우에만 가능합니다. 현재 그러한 태그 라이브러리가 없습니다.
문제 #3: 간단한 작업은 여전히 피곤합니다.
머리글과 바닥글을 포함하는 간단한 작업조차 JSP에서는 여전히 매우 어렵습니다. 모든 페이지에 포함될 "머리글" 및 "바닥글" 템플릿이 있고 각 템플릿에는 콘텐츠의 현재 페이지 제목이 포함되어야 한다고 가정합니다.
JSP에서 가장 좋은 방법은 다음과 같습니다.
<% 문자열 제목 = "페이지 제목" %>
<%@ include file="/header.jsp" %>
...페이지 콘텐츠...
<%@ include file="/footer.jsp" %>
페이지 디자이너는 첫 번째 줄의 세미콜론을 생략하지 말고 제목을 문자열로 정의해야 합니다. 또한 /header.jsp 및 /footer.jsp는 루트 디렉토리에 있어야 하며 완전히 액세스 가능한 파일이어야 합니다.
WebMacro에 머리글과 바닥글을 포함하는 것은 비교적 간단합니다.
#set $title = "페이지 제목"
#"header.wm" 구문 분석
여기에 귀하의 콘텐츠가 있습니다
#parse "footer.wm"
디자이너가 기억해야 할 세미콜론이나 제목 정의가 없으며 .wm 파일을 사용자 정의 가능한 검색 경로에 배치할 수 있습니다.
문제 #4: 매우 두꺼운 루프
JSP에서의 루프는 어렵습니다. 여기서 JSP는 각 ISP 객체의 이름을 반복적으로 출력하는 데 사용됩니다.
<%
열거형 e = list.elements();
동안(e.hasMoreElements()) {
out.print("다음 이름은 ");
out.println(((ISP)e.nextElement()).getName());
out.print("
");
}
%>
언젠가 이러한 루프를 수행하기 위한 사용자 정의 태그가 있을 수도 있습니다. "if"도 마찬가지입니다. JSP 페이지는 이상한 Java 코드처럼 보일 수 있습니다. 동시에 웹 매크로 루프도 아름답습니다.
#foreach $isp in $isps {
다음 이름은 $isp.Name입니다.
}
필요한 경우 #foreach 지시문은 사용자 정의 #foreach-backwards 지시문으로 쉽게 대체될 수 있습니다.
jsp를 사용하는 경우 다음과 같이 될 수 있습니다. (여기에
다음 이름은
입니다.
디자이너는 당연히 전자를 선택하게 될 것입니다.
문제 #5: 쓸모없는 오류 메시지
JSP에는 종종 놀라운 오류 메시지가 있습니다. 이는 페이지가 먼저 서블릿으로 변환된 다음 컴파일되기 때문입니다. 좋은 JSP 도구는 오류 위치를 찾을 가능성을 상대적으로 높일 수 있지만, 최고의 도구라도 모든 오류 메시지를 쉽게 읽을 수 있도록 만들 수는 없습니다. 변환 프로세스로 인해 일부 오류는 도구에서 식별이 불가능할 수 있습니다.
예를 들어, JSP 페이지가 모든 페이지에 공통적인 제목을 생성해야 한다고 가정합니다. 다음 코드에는 아무런 문제가 없습니다.
<% static String title = "Global title" %>
그러나 Tomcat은 다음과 같은 오류 메시지를 제공합니다.
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: 명령문이 필요합니다.
정적 정수 개수 = 0;
^
본 정보는 위의 스크립트가 _jspService() 메소드에 들어가고 정적 변수는 메소드에 들어갈 수 없는 것으로 간주됩니다. 구문은 <%!%>여야 합니다. 페이지 디자이너가 이러한 오류 메시지를 읽는 것은 어렵습니다. 최고의 플랫폼이라도 이 점에서는 부족합니다. 모든 Java 코드를 페이지 밖으로 이동해도 문제가 해결되지 않습니다. 또한, 다음 표현에는 어떤 문제가 있나요?
<% 개수 %>
톰캣은 다음을 제공합니다:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: 클래스 수를 찾을 수 없습니다.
유형 선언.
세다
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: 잘못된 선언입니다.
out.write("rn");
^^
즉, 단지 누락된 표시일 뿐입니다. <%= 개수 %>여야 합니다.
템플릿 엔진은 코드로의 급격한 변환 없이 템플릿 파일에서 직접 생성될 수 있으므로 적절한 오류 보고를 제공하는 것이 매우 쉽습니다. 비유하자면 유닉스 셸의 명령줄에 C 언어 명령을 입력할 때 셸이 해당 명령을 실행하는 C 프로그램을 생성하는 것을 원하지 않고 단순히 명령을 해석하고 실행하기 위한 셸만 있으면 됩니다. 오류가 있으면 직접 보고하세요.
문제 #6: 컴파일러 필요
JSP에는 웹 서버에 컴파일러가 있어야 합니다. Sun이 javac 컴파일러가 포함된 tools.jar 라이브러리를 포기하지 않았기 때문에 이것이 문제가 되었습니다. 웹 서버에는 IBM의 Jikes와 같은 타사 컴파일러가 포함될 수 있습니다. 그러나 이러한 컴파일러는 모든 플랫폼(C++로 작성)에서 원활하게 작동하지 않으며 순수 Java 웹 서버를 구축하는 데 도움이 되지 않습니다. JSP에는 완벽하지는 않지만 도움이 되는 사전 컴파일 옵션이 있습니다.
문제 #7: 공간 낭비
JSP는 추가 메모리와 하드 디스크 공간을 소비합니다. 서버에 있는 모든 30K JSP 파일에 대해 30K보다 큰 해당 클래스 파일을 생성해야 합니다. 하드 드라이브 공간을 효과적으로 두 배로 늘립니다. JSP 파일은 언제든지 <%@ include>를 통해 대용량 데이터 파일을 쉽게 포함할 수 있다는 점을 고려하면 이러한 우려는 매우 실용적인 의미를 갖는다. 동시에 각 JSP의 클래스 파일 데이터를 서버의 메모리에 로드해야 합니다. 이는 서버의 메모리가 전체 JSP 문서 트리를 영원히 저장해야 함을 의미합니다. 일부 JVM에는 클래스 파일 데이터를 메모리에서 이동할 수 있는 기능이 있지만 프로그래머는 일반적으로 재선언 규칙을 제어할 수 없으며 대규모 사이트에서는 재선언이 그다지 효율적이지 않을 수 있습니다. 템플릿 엔진의 경우 두 번째 파일이 생성되지 않으므로 공간이 절약됩니다. 또한 템플릿 엔진은 프로그래머에게 템플릿이 메모리에 캐시되는 방식을 완벽하게 제어할 수 있는 기능을 제공합니다.
템플릿 엔진을 사용하는 데에도 몇 가지 문제가 있습니다.
템플릿 문제 #1: 엄격하게 정의되지 않았습니다.
템플릿 엔진이 어떻게 작동해야 하는지가 엄격하게 정의되어 있지 않습니다. 그러나 JSP와 비교하면 이는 실제로 그다지 중요하지 않습니다. JSP와 달리 템플릿 엔진에는 웹 서버에 대한 특별한 요구 사항이 없습니다. 서블릿을 지원하는 모든 서버는 템플릿 엔진을 지원할 수 있습니다(Apache/JServ와 같은 API 2.0 서버 포함). JSP를 완벽하게 지원하지 않음) 최고의 템플릿 엔진 디자인을 위한 건전한 경쟁이 특히 오픈 소스의 홍보로 눈부신 혁신을 일으킬 수 있었다면(아이디어가 서로 밀고 홍보할 수 있도록 허용) 오늘날의 WebMacro는 Perl과 같을 것입니다. .엄격하게 정의된 것은 아니지만 오픈소스 조직의 홍보가 표준입니다.
템플릿 문제 #2: 인식되지 않음
템플릿 엔진은 널리 알려져 있지 않습니다. JSP는 거대한 상업 시장을 점유하며 사람들의 마음 속에 깊이 뿌리내리고 있습니다. g 템플릿 엔진의 사용은 이해되지 않는 대체 기술일 수 밖에 없습니다.
템플릿 문제 #3: 배포되지 않음
템플릿 엔진이 아직 고도로 구성되지 않았습니다. 템플릿 엔진과 JSP 간의 성능 테스트 및 비교는 없습니다. 이론적으로 잘 배포된 템플릿 엔진 구현은 잘 배포된 JSP와 일치해야 합니다. 그러나 제3자가 jsp에 대해 엄청난 추진을 했다는 점을 고려하면 jsp만이 잘 배포되었습니다.
JSP의 역할
물론 JSP는 미래에도 확실히 그 자리를 차지하게 될 것입니다. JSP와 ASP의 유사성은 이름에서도 알 수 있으며 문자 하나만 다릅니다. 따라서 ASP를 사용하는 사람들이 Java로 전환하게 되면 이를 촉진하는 데 매우 유사한 JSP 환경이 큰 역할을 할 것입니다. ASP와의 상응하는 관계를 유지하는 역할도 JSP를 출시하는 디자이너에게 중요한 고려 사항이 될 것입니다.
그러나 여기서 중요한 점은 직원들이 새로운 환경으로 이동하는 데 어떤 이점이 있는지와 그것이 실제로 해당 환경을 사용하는 가장 좋은 방법인지 여부에는 큰 차이가 있다는 것입니다.
JSP는 점점 더 중요한 Java 기술 중 하나로 자리매김하고 있으며 사람들이 ASP의 세계를 떠날 수 있게 해줍니다. 따라서 Sun은 이러한 강력한 비즈니스 사례를 지원할 것이며 Java 관련 기술 지지자들도 더 큰 지원을 제공할 것입니다.
그러나 이는 Java 플랫폼에 가장 적합한 솔루션은 아닙니다. 이렇게 하면 Java 솔루션이 Java가 없는 솔루션처럼 보입니다.