템플릿
엔진 Smarty에 대한 심층 소개 - PHP
출처
: cjjer MVC 개발 모델의 논리 계층 및 프레젠테이션 계층을 구현하기 위해 PHP를 사용하도록 몇 가지 변경 사항을 적용했습니다
. 선택할 수 있는 템플릿 엔진은 다양하지만 탄생 이후입니다. 공식 엔진 SMARTY의 선택이 바뀌었습니다. 그 개념과 구현은 상당히 아방가르드합니다. 이 글에서는 주로 SMARTY의 다른 템플릿 엔진과의 차이점을 논의하고, 엔진의 설치 및 사용법을 간략하게 소개하고, 작은 테스트 케이스를 사용하여 SMARTY와 PHPLIBtemplate의 속도와 사용 편의성을 비교합니다.
1. MVC는 템플릿이 필요합니다.
MVC는 SmallTalk 언어 개발 과정에서 처음으로 디자인 패턴으로 요약되었습니다. MVC는 각각 모델, 뷰 및 제어를 나타냅니다. 그 목적은 다양한 개발 역할이 대규모 및 중간 규모에서 각자의 임무를 수행할 수 있도록 하는 것입니다. 프로젝트. 네트워크 애플리케이션 개발에서 다음 다이어그램을 사용하여 개념 간의 관계를 나타낼 수 있습니다.
이 그림은 간단한 WEB 애플리케이션을 보여줍니다. 사용자가 브라우저에서 보는 정보는 데이터베이스 서버에 있는 내용이지만 이전에 애플리케이션 서버에서 처리된 내용입니다. 개발자는 데이터 구조, 데이터 처리 논리, 데이터 표현 방법을 설정하는 역할을 담당합니다.
1996년 중국에서 CGI가 대중화되었을 때 초기 WEB 프로그래머들은 모두 HTML을 독학하여 PERL에서 HTML 라인을 인쇄하는 것이 어렵지 않았습니다. 그러나 네트워크 속도가 단계적으로 증가함에 따라 페이지 크기도 증가했습니다. 원래 20~30K에서 10배나 급증했습니다. CGI 프로그램을 작성하려면 PERL과 HTML 소스 코드를 분리해야 한다는 긴급한 요구 사항이 필요합니다. 따라서 사회적 발전은 개발팀 내 업무 분담에 반영됩니다. 아티스트와 프로그래머는 서로의 작업에 대해 그다지 익숙하지 않기 때문에 협업 시 의사소통을 위해서는 합의된 언어를 사용해야 합니다.
이 언어는 우리의 모국어나 영어가 아니며, 템플릿이라고 불리는 용어이며 이에 따라 논리와 표현이 달라집니다. HTML과 스크립팅 언어의 특성을 결합한 표현 방식입니다. 이를 통해 프리젠테이션 레이어는 로직 레이어에서 처리된 데이터를 사용자가 원하는 형태로 디스플레이할 수 있다. Windows 플랫폼에서 MFC 개발 경험이 있다면 Document/DocumentTemplate/View의 캡슐화에 확실히 익숙할 것입니다. 이것은 매우 일반적인 MVC 예입니다. 웹 애플리케이션의 경우 개인적으로 J2EE의 EJB/servlets/JSP가 가장 강력하다고 생각하며, 물론 간단하고 아름다운 Structs도 있습니다. 또 다른 잘 알려진 구현은 COM/DCOM+ASP입니다. 이 조합은 우리나라에서 가장 많은 사람들이 사용합니다.
WEB 애플리케이션의 여러 MVC 구현을 비교함으로써 템플릿에 대한 개념을 얻을 수 있습니다. 즉, HTML에 삽입된 스크립트 세트 또는 삽입된 콘텐츠가 변화하는 데이터를 나타내는 스크립트 HTML입니다. 다음은 템플릿 파일의 예입니다. 처리 후 이 템플릿은 브라우저에 Hello, world!를 표시합니다.
$greetings
의 처리 방법은현재 생략되었으며, 비교를 위해 나중에 다루도록 하겠습니다.
2. SMARTY를 선택하는 이유는 무엇입니까?
PHP의 경우 초기 PHPLIB템플릿과 떠오르는 스타 Fasttemplate 등 선택할 수 있는 템플릿 엔진이 많이 있습니다. 현재 가지고 있는 템플릿 엔진에 매우 만족하신다면... 계속 읽어보시기 바랍니다. 저는 자유 소프트웨어 매니아나 효율성과 우아함을 추구하는 개발자로서 다음 SMARTY 소개가 다소 흥미로울 것이라고 믿습니다.
개인적 선호의 영향 외에도 나는 항상 APACHE의 XML 엔진 Axis와 같은 공식 표준 구현을 사용하는 경향이 있었습니다. 장점은 가능한 최고의 호환성을 얻을 수 있다는 것입니다(예를 들어 초기 MFC와 Win3x의 호환성은 다른 애플리케이션 프레임워크보다 우수했으며 물론 이제 모든 버전이 매우 완벽합니다). SMARTY가 출시되기 전에는 PEAR에서 Integrated Template eXtension을 사용하고 있었습니다. 이 엔진은 PHPLIBtemplate 및 Fasttemplate과 거의 호환됩니다. 템플릿 구문부터 템플릿 처리까지 템플릿을 메모리로 읽어온 다음,parse() 함수를 호출하여 미리 설정된 태그를 데이터로 대체합니다.
SMARTY가 어떻게 하는지 살펴보겠습니다. 요청을 받은 후 먼저 해당 URL이 처음으로 요청되었는지 확인합니다. 그렇다면 해당 URL에 필요한 템플릿 파일을 PHP 스크립트로 컴파일한 다음 리디렉션하지 않으면 해당 URL의 템플릿이 요청되었음을 의미합니다. 확인 재컴파일하지 않고 즉시 리디렉션할 수 있습니다. 재컴파일 조건은 고정된 시간 제한으로 설정할 수 있습니다. 기본값은 템플릿 파일을 수정하는 것입니다.
어때요? 친숙해 보이죠? 그러고 보니──이것이 JSP의 원리가 아닐까! 실제로 이런 종류의 컴파일은 PHP와 같은 해석된 스크립팅 엔진에서 사용하면 믿을 수 없을 것 같지만, 잘 생각해보면 JAVA도 JVM에 의해 해석되고 실행되는 것이 아닐까? 이는 불가능한 것은 없고 상상할 수 없을 뿐이라는 뜻이다.
이제 JAVA에 대해 이야기했으니 PHP의 미래에 대한 나의 견해를 말씀드리겠습니다. 공식 PHP 웹사이트에서는 PHP 5.0 버전이 2003년 말에 출시될 것이라고 발표했습니다. 이 버전에는 예외 처리, 네임스페이스, 보다 객체 지향적인 등 많은 새로운 기능이 포함되어 있습니다. JAVA에 점점 가까워지고 있다고 할 수 있으며, SMARTY도 새로운 기능 중 하나로 PHP를 중대형 프로젝트 개발에 더욱 적합하게 만들어줍니다. 하지만 애초에 선택한 이유인 유연성과 사용의 용이성과는 점점 멀어지는 것 같습니다. 그러나 소프트웨어의 라이프사이클 관점에서 볼 때, PHP는 성장 단계에 있으며, 개발자가 상용 애플리케이션에 적합할 수 있기를 바라면서 PHP에 더 많은 기능을 제공하는 것은 단점보다 장점이 더 많습니다. PHP를 충성스럽게 사용하는 사용자라면 PHP가 항상 기능이 부족하다는 비난을 받는 것을 원하지 않을 것입니다. 그렇죠?
단지 JSP와 유사하다는 이유만으로 SMARTY를 선택하는 이유는 무엇입니까? 확실히 더 나은 이유가 있습니다. 우선, 첫 번째 컴파일의 상대적으로 높은 비용 외에도 템플릿 파일이 수정되지 않는 한 컴파일된 캐시 스크립트를 언제든지 사용할 수 있어 많은 구문 분석() 시간을 절약할 수 있습니다. 둘째, SMARTY는 다음과 같은 이점을 제공합니다. PHP와 같은 풍부한 기능 라이브러리. 단어 계산부터 자동 들여쓰기, 텍스트 줄 바꿈 및 정규식까지, 충분하지 않다고 생각되면 직접 사용할 수 있습니다. 예를 들어 데이터 결과 집합의 페이징 표시 기능이 필요합니다. 또한 플러그인을 통해 확장할 수 있는 강력한 확장 기능도 갖추고 있습니다.
사실은 말보다 더 크게 말합니다. 테스트 프로그램을 설계하고 속도와 개발 난이도라는 두 가지 요소를 바탕으로 SMARTY와 PHPLIBtemplate을 비교했습니다. 제가 PHPLIBtemplate을 선택한 이유는 Patrick의 기사 "PHP 세계에서 가장 적합한 템플릿 선택"에서 PHPLIB 간의 비교가 있기 때문입니다. template 및 Fasttemplate 경쟁에서 PHPLIBtemplate이 큰 승리를 거두어 SMARTY가 좋은 상대가 되었습니다. 테스트에 앞서, 설치 과정에서 주의해야 할 사항에 대해 이야기해보겠습니다.
3. 발생할 수 있는 문제
SMARTY 공식 웹사이트에 자세한 사용 설명서가 있으며 HTML 및 PDF 형식의 온라인 버전을 선택할 수 있습니다. 여기서는 설명서의 기존 내용을 다루지 않고 처음 사용하는 동안 발생할 수 있는 문제만 설명합니다.
첫 번째 질문은 매우 치명적입니다. 필요한 파일을 찾을 수 없다고 나옵니다. 모든 사람이 SMARTY의 기본 디렉터리 구조에 따라 응용 프로그램을 작성하는 것은 아닙니다. 이는 디렉토리 구조가 다음과 같다고 가정하여 수동으로 지정해야 합니다.
index.php에서 디렉토리 구조를 지정해야 합니다:
$smart->template_dir = "smarty/templates/";
$smart->compile_dir = "smarty/templates_c/";
$smart->config_dir = "smarty/configs/";
$smart->cache_dir = "smarty/cache/";
첫 번째 문제가 해결되고 두 번째 문제가 발생합니다. 방금 Dreamweaver로 생성한 아름다운 템플릿을 왜 사용할 수 없습니까? 템플릿 파일에 문제가 있는 것은 아닙니다. SMARTY의 기본 태그 구분 기호가 {}이고 불행하게도 Javascript에 이 태그가 확실히 포함되어 있기 때문입니다. 다행히 모든 문자를 구분 기호로 사용할 수 있으며 다음 두 문장도 사용할 수 있습니다.
$smart->left_delimiter = "{/";
$smart->right_delimiter = "/}";
이제 기본적으로 설치가 완료되었습니다. 문제없습니다.
4. 대조와 유추
먼저, 테스트 디자인에 대해 생각해 보세요. 주요 판단 요소는 물론 속도입니다. 속도 테스트에는 산술 평균이 사용되었습니다. 테스트 페이지에서 페이지 생성을 N회 반복한 후 총 페이지 생성 시간을 비교합니다. 또 다른 중요한 요소는 사용 편의성(확장성의 경우 결과를 비교할 필요가 없음)이므로 사용되는 템플릿이 너무 작을 수 없습니다. 저는 Firework+Dreamweaver로 생성된 약 7K 크기의 HTML 파일인 개인 홈페이지 페이지를 사용합니다. 변수 설정은 또한 PHPLIB 템플릿에서는 블록이라고 하고 SMARTY에서는 섹션이라고 하는 가장 일반적으로 사용되는 블록을 채택합니다. 이름의 차이를 과소평가하지 마세요. 사용성 기준은 템플릿 파일과 스크립트 파일의 구문이 간결하고 사용하기 쉬운지 여부라는 두 부분으로 나뉩니다.
테스트에 대해 살펴보겠습니다. 먼저 두 템플릿 파일의 구문을 살펴보겠습니다. 파란색 막대의 왼쪽은 PHPLIB 템플릿이고 오른쪽은 SMARTY에 속합니다. 개인 취향이 다르므로 여기서는 언급하지 않겠습니다. 스크립트의 처리 명령문을 비교하는 데 중점을 두고 먼저 PHPLIB 템플릿을 살펴보세요.
$tpl->set_file('phplib', 'bigfile.htm');
$tpl->set_block('phplib', 'row', 'rows');
for ($j = 0; $j < 10; $j++){
$tpl->set_var('tag' ,"$j");
$tpl->parse('rows', 'row', true);
}
$tpl->parse('out', 'phplib');
$tpl->p('out');
다음은 SMARTY입니다:
$smart->assign('row',$row);
$smart->display('bigfile.htm');
SMARTY는 태그와 행이라는 두 가지 변수만 사용하는 반면 PHPLIB 템플릿에는 추가 템플릿 파일 핸들러와 설명할 수 없는 출력이 있습니다. 솔직히 말해서 처음 배웠을 때는 왜 이런 게 존재하는지 몰랐어요. 지금도 어색해요. SMARTY에는 왜 처리 명령문이 그렇게 적나요? 대답은 작업이 엔진에 의해 수행된다는 것입니다. 소스 프로그램을 자세히 살펴보고 싶다면 Smarty_compiler.class.php에 섹션 태그를 PHP 문으로 변환하는 _compile_tag()라는 함수가 있다는 것을 알 수 있습니다. 이는 일반적인 라벨이 아니며, 스크립트 프로그래밍의 작업량을 줄여주는 매개변수와 데이터가 포함되어 있어 템플릿 라벨의 작업량은 크게 다르지 않습니다.
이제 속도에 집중할 차례입니다. 숙련된 웹 개발자에게는 학습 곡선이 완만한 기술인 템플릿 엔진은 말할 것도 없고 가장 어려운 도구도 익히는 것은 시간 문제일 뿐입니다. 속도는 웹 애플리케이션의 생명이며, 특히 동시 방문 수가 많은 사이트에서 템플릿 엔진을 사용하는 경우 이는 더욱 중요합니다. 테스트를 시작하기 전에는 PHPLIB 템플릿이 여러 번 업그레이드되었고 기본적으로 버그가 없기 때문에 이 측면에서 승리할 것이라고 생각했습니다. 게다가 SMARTY의 엔진은 파일이 두 개밖에 없는 상대와 달리 너무 큽니다.
물론 테스트 결과는 아래와 같습니다. PHPLIB 템플릿은 25%의 속도 이점을 제공합니다.
하지만 항상 이렇지는 않을 것입니다. 새로고침을 다시 눌렀는데 이번에는 다른 결과가 나왔습니다.
PHPLIB는 기본적으로 변함이 없으나 SMARTY로 인해 속도가 25% 향상되었습니다. 계속해서 새로 고치면 두 번째와 비슷한 결과를 얻게 됩니다. SMARTY는 PHPLIB 템플릿보다 거의 10% 빠릅니다. 이것이 컴파일된 버전이 해석된 버전보다 빠른 이유라고 생각합니다. SMARTY 엔진 자체가 매우 크고, 템플릿을 php 파일로 컴파일해야 하기 때문에 확실히 컴팩트한 PHPLIB 템플릿만큼 속도가 빠르지는 않습니다. 그러나 이것은 처음에만 해당됩니다. 두 번째 요청을 받았을 때 SMARTY는 템플릿이 이미 컴파일되어 있는 것을 발견하여 가장 시간이 많이 걸리는 단계를 건너뛰고 상대는 검색 및 교체를 단계별로 수행해야 했습니다. 이는 편찬의 원칙에서 언급한 '시간과 공간의 교환'의 전형적인 예이다.
5. 결론
결론은 SMARTY와 사랑에 빠졌다면 무엇을 기다리고 계십니까? 물론 이것이 전능하다는 의미는 아닙니다. MVC 모델을 사용하여 개인 웹 사이트를 작성할 때처럼 작업량이 줄어들 뿐만 아니라 항상 서로 다른 수준 간의 결합에 대해 걱정해야 합니다.
SMARTY가 적합하지 않은 것은 무엇입니까? 매뉴얼에서 전형적인 예를 들어보자: 일기예보 웹사이트. 또 하나 떠오르는 것이 바로 주식시장이다. 이러한 웹사이트에서는 SMARTY를 사용하는 것이 잦은 재컴파일로 인해 비효율적이므로 PHPLIB 템플릿이 더 적합합니다.
이 기사는 두 엔진을 비교하는 것이 아니라 SMARTY의 장점을 설명하기 위한 것입니다. 이를 사용하는 데 있어 가장 의미 있는 점은 새로운 PHP 시스템의 일부로서 독립적인 힘으로 .NET과 JAVA ONE이라는 두 가지 주요 시스템 외에도 대규모 및 중간 규모 웹 개발을 위한 다른 옵션이 있다는 것입니다. GNU 프로젝트에서 그 의미는 Liu와 Deng의 군대가 Dabie 산맥으로 수천 마일을 도약하는 것과 다르지 않습니다.
저자: 유복상