오래된 글이지만 스마트 템플릿 엔진에 대해 소개하는 지식은 지금도 참고용으로 공유합니다. PHP를 사용하는 MVC 개발 모델의 로직 레이어와 프리젠테이션 레이어에 대해 선택할 수 있는 템플릿 엔진은 다양하지만, 공식 엔진인 SMARTY가 탄생한 이후 선택이 바뀌었습니다. 그 개념과 구현은 상당히 "아방가르드"적입니다. 이 글에서는 다른 템플릿 엔진과 비교하여 SMARTY의 다양한 특징을 주로 논의하고, 엔진의 설치 및 사용법을 간략하게 소개하고, 작은 테스트 사례를 사용하여 SMARTY 및 PHPLIB 템플릿의 속도와 사용 편의성을 비교합니다. 1. MVC에는 템플릿이 필요합니다 MVC는 SmallTalk 언어 개발 과정에서 처음으로 디자인 패턴으로 요약되었습니다. MVC는 각각 "모델", "뷰" 및 "제어"를 의미합니다. 그 목적은 다양한 개발 역할이 전체적으로 다른 역할을 할 수 있도록 하는 것입니다. 중간 규모 프로젝트를 수행합니다. 네트워크 애플리케이션 개발에서 다음 다이어그램을 사용하여 개념 간의 관계를 나타낼 수 있습니다. 이 그림은 간단한 WEB 애플리케이션을 보여줍니다. 사용자가 브라우저에서 보는 정보는 데이터베이스 서버에 있는 내용이지만 이전에 애플리케이션 서버에서 처리된 내용입니다. 개발자는 데이터 구조, 데이터 처리 논리, 데이터 표현 방법을 설정하는 역할을 담당합니다. 1996년 중국에서 CGI가 대중화되었을 때 초기 WEB 프로그래머들은 모두 HTML을 독학했습니다. PERL에서 HTML 줄을 인쇄하는 것은 어렵지 않았지만 인터넷이 단계적으로 속도가 빨라지면서 페이지 크기도 커졌습니다. 원래 20K에서 30K로 10배 증가했습니다. CGI 프로그램을 작성하려면 PERL과 HTML 소스 코드를 분리해야 한다는 긴급한 요구 사항이 필요합니다. 따라서 사회적 발전은 개발팀 내 업무 분담에 반영됩니다. 아티스트와 프로그래머는 서로의 작업에 대해 그다지 익숙하지 않기 때문에 협력 중에 의사소통하려면 합의된 "언어"를 사용해야 합니다. 이 언어는 우리의 모국어나 영어가 아니며, 용어는 "템플릿"이라고 하며 이에 따라 논리와 표현이 달라집니다. HTML과 스크립팅 언어의 특성을 결합한 표현 방식입니다. 이를 통해 프리젠테이션 레이어는 로직 레이어에서 처리된 데이터를 사용자가 원하는 형태로 디스플레이할 수 있다. Windows 플랫폼에서 MFC 개발 경험이 있다면 Document/Document Template/View의 캡슐화에 확실히 익숙할 것입니다. 이것은 매우 일반적인 MVC 예입니다. 웹 애플리케이션의 경우 개인적으로 J2EE의 EJB/서블릿/JSP가 가장 강력하다고 생각하며, 물론 간단하고 아름다운 Structs도 있습니다. 또 다른 잘 알려진 구현은 COM/DCOM ASP입니다. 이 조합은 우리나라에서 가장 많은 사람들이 사용합니다. 웹 애플리케이션의 여러 MVC 구현을 비교함으로써 템플릿, 즉 HTML에 삽입된 스크립트 세트 또는 삽입된 콘텐츠가 변화하는 데이터를 나타내는 스크립트 HTML에 대한 개념을 얻을 수 있습니다. 다음은 템플릿 파일의 예입니다. 이 템플릿은 브라우저에 "Hello, world!"를 표시하도록 처리됩니다.
여기서 처리 방법은 당분간 생략하며, 추후 비교를 위해 구체적으로 논의하겠습니다. 2. 왜 SMARTY를 선택하나요? PHP에는 초기 PHPLIB 템플릿과 떠오르는 Fast 템플릿 등 선택할 수 있는 템플릿 엔진이 많이 있습니다. 여러 번의 업그레이드를 거쳐 상당히 성숙하고 안정적이 되었습니다. 현재 가지고 있는 템플릿 엔진에 매우 만족하신다면... 계속 읽어보시기 바랍니다. 저는 자유 소프트웨어 매니아나 효율성과 우아함을 추구하는 개발자로서 다음 SMARTY 소개가 다소 흥미로울 것이라고 믿습니다. 개인 취향을 제외하고 저는 항상 APACHE의 XML 엔진 Axis와 같은 공식 표준 구현을 사용하는 경향이 있었습니다. 장점은 가능한 최고의 호환성을 얻을 수 있다는 것입니다(예를 들어 초기 MFC와 Win3x의 호환성은 다른 애플리케이션 프레임워크보다 우수했으며 물론 이제 모든 버전이 매우 완벽합니다). SMARTY가 출시되기 전에는 PEAR에서 Integrated Template eXtension을 사용하고 있었습니다. 이 엔진은 PHPLIB 템플릿 및 Fast 템플릿과 거의 호환됩니다. 템플릿 구문부터 템플릿 처리까지 템플릿을 메모리로 읽어온 다음, 미리 설정된 태그를 데이터로 대체하기 위해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와 PHPLIB 템플릿을 비교했습니다. 제가 PHPLIB 템플릿을 선택한 이유는 Patrick의 기사 "PHP 세계에서 가장 적합한 템플릿 선택"에 PHPLIB 템플릿이 있기 때문입니다. Fast 템플릿 경쟁에서는 PHPLIB 템플릿이 큰 승리를 거두며 SMARTY가 좋은 상대가 되었습니다. 테스트에 앞서, 설치 과정에서 주의해야 할 사항에 대해 이야기해보겠습니다. |