(Library) [SMARTY] PHP를 위한 템플릿 엔진

철학

스마티는 아래의 목표를 만족시키기 위해 설계되었다.
• 프레젠테이션 코드와 어플리케이션 코드의 명확한 분리
• 백엔드에서는 PHP를, 프론트엔드에서는 스마티 템플릿을
• PHP를 보완하지, 대체하지는 않는다
• 프로그래머와 디자이너가 빠르게 개발해서 배포해야 한다
• 유지보수를 쉽고 빠르게 할 수 있어야 한다.
• PHP 지식이 없더라도 구문은 이해하기 쉬워야 한다.
• 쉽게 확장할 수 있는 유연성
• 보안 : PHP로부터 분리
• 무료, 오픈소스

스마티란?

스마티는 PHP를 위한 템플릿 엔진으로, 스마티를 사용하면 프레젠테이션 로직(HTML/CSS)와 어플리케이션 로직을 분리할 수 있다. 다시 말해 PHP 코드는 어플리케이션 로직을 위해서만 사용하며, 프레젠테이션으로부터는 분리할 수 있다.

템플릿에 대한 두 진영간의 의견 대립
PHP에서 템플릿을 사용한다고 할 때, 여기에는 서로 상반대는 두 진영이 있다. 한 진영에서는 “PHP 그 자체가 템플릿 엔진”이라고 주장한다. 이 진영에서는 PHP 코드와 HTML을 단순히 섞어서 사용한다. 순전히 스크립트를 실행한다는 관점에서 보면 이 방식은 빠르긴 하다. 하지만 대다수의 사람들은 PHP 코드가 프레젠테이션 코드와 섞어서 사용하게 되면 구문이 지저분해지며, 결국 유지보수 하기귀 십자 않다고 반대한다. PHP는 프로그래밍에는 적합하지만, 템플릿으로 사용하기엔느 적합하지 않기 때문이다.

반대 진영에서는 프리젠테이션에는 어떤 프로그래밍 코드가 있어서는 안되며, 어플리케이션 컨텐츠가 필요한 위치에는 단순한 태그를 사용해야 한다고 주장한다. 이러한 사상은 대다수의 템플릿 엔진(또한 프로그래밍 언어)이 지닌 철학과 일맥상통하며, 스마티에서 이와 동일한 입장을 취한다. 즉 별도의 노력을 들이지 않고도 템플릿에서는 프레젠테이션에만 집중하며, 어플리케이션 로직은 사용하지 않자는 것이다.

PHP와 템플릿을 분리하는 일이 왜 중요한가?

PHP 코드와 템플릿을 분리하게 되면 많은 장점이 있다. 예를 들어 다음과 같다.
• 구문(Syntax)
템플릿은 주로 HTML과 같은 의미적인 마크업(semantic markup)으로 구성된다. PHP 구문은 어플리케이션에는 적합하지만, HTML과 섞어 쓰게 되면 문제가 되기 쉽상이다. {tag}와 같은 간단한 스마티 구문은 다른 무엇보다도 프레젠테이션을 표현하기 위해 만들어졌다. 스마티를 사용하면 프레젠테이션에만 집중할 수 있으며, “코드”에는 신경을 쓰지 않아도 된다. 이를 통해 템플릿을 십게 배포할 수 있으며, 유지보수 또한 쉬워진다. 스마티 구문을 사용하기 위해서 PHP에 대한 별도의 지식을 필요료하지 않는다. 또한 스마티 구문은 프로그래머뿐만 아니라 프로그래머가 아닌 사람들도 이해하기 쉽다.
• 기능(Feature)
템플릿 엔진을 사용하면 다양한 프레젠테이션 기능을 사용할 수 있다. 만약 템플릿을 엔진을 사용하지 않았더라면, 여러분이 직접 개발하고 테스트해야 하며, 유지보수 해야했을 것이다. 뿐만 아니라 태그를 사용하면, PHP 문장의 복잡성을 숨길 수 있게 된다. 예를 들어 아래의 PHP 코드를
PHP
<?php echo strtolower(htmlspecialchars($title,ENT_QUOTES,UTF-8)); ?>
스마티에서는 아래와 같이 작성할 수 있다.
Smarty
{$title|escape|lower}
좀더 쉽게 개발을 하기 위해서 PHP가 C 레이어 위에서 추상화를 제공한 것과 마찬가지로, 템플릿 유지를 쉽게 하기위해 스마티는 PHP 레이어 위에서 추상화를 제공한다.
• 샌드박스(Sandbox)
PHP를 템플릿과 섞어 쓰게 되면, 템플릿에 포함될 수 있는 로직에 대한 제약을 할 수 없게 된다. 스마티는 템플릿을 PHP로부터 분리하므로, 프레젠테이션과 비즈니스 로직의 분리를 제어할 수 있게 된다. 또한 스마티는 보안 측면에서 템플릿을 점진적으로 제한할 수 있는 기능을 제공한다.
PHP 구문과 스마티 구문을 비교가 궁금하다면, 구문 비교를 참고하라.

웹 디자이너와 PHP

“어쨋든 웹 디자이너는 구문을 배워야만 하는데, PHP는 왜 배우면 안되는가”라고 흔히들 묻는다. 물론 웹 디자이너도 PHP를 배울 수 있고, 심지어는 이미 익숙할 수도 있다. 중요한 점은 웹 디자이너가 PHP를 배울 능력이 되느냐가 아니라, PHP와 HTML을 섞어 썼을 떄 과연 유지보수가 쉬우냐다. {tags}는 간단하며, 이해하기 쉽고, PHP 구문에 비해 실수할 가능성도 적다. 또한 템플릿은 템플릿에 포함될 수 있는 코드에 제약을 가할 수 있다. PHP를 사용하게 되면 템플릿에 포함하지 말아야 할 코드를 템플릿에 포함하게 되는 우를 범하게 될 가능성이 높다. 물론 어플리케이션 설계 규칙에 대해 디자이너에게 설명해줄 수는 있지만, 사실 이러한 과정을 불필요한 작업이다(만약 디자이너가 어플리케이션 설계 규칙을 배운다면 이미 디자이너는 디자이너가 아니라 개발자인 셈이다!). PHP 매뉴얼은 개발자를 위한 것이다. 디자이너는 매뉴얼의 일부만 알고 있으면 되며, 디자이너가 매뉴얼에서 자신이 필요한 요소를 찾기란 쉽지 않다. 이러한 상황에서 스마티는 디자이너가 필요로 하는 최적의 툴이다. 또한 개발자는 스마티를 완전히 제어할 수 있다. 템플릿 상속과 같은 프레젠테이션을 위한 여러 기능도 제공되므로, 템플릿 재사용할 수 있을 뿐만 아니라 능률적으로 구조화할 수 있게 된다.

구현이 중요하다

스마티가 프레젠테이션과 어플리케이션 코드를 명확히 분리할 수 있는 도구를 제공하지만, 분리 규칙을 어기게 되는 상황도 충분히 많이 존재한다. 예를 들어 구현을 잘못한 경우(PHP를 템플릿에 포함하는 것과 같은), 프레젠테이션 분리를 통해 해결하고자 했던 문제보다 더 큰 문제를 야기할 수 있다. 스마티 문서에서는 유의해야할 항목들에 대해 잘 설명하고 있다. 또한 베스트 프랙티스를 살펴보라.

스마티는 무엇이며, 어떻게 사용해야 하는가?

크래쉬 코스에서 PHP 어플리케이션에서 스마티를 사용하여 전형적으로 구현하는 방식에 대한 개요를 잘 설명하고 있다.

어떻게 동작하나?

스마티는 내부적으로 템플릿과 PHP 스크립트 복사본을 컴파일한다. 이를 통해 템플릿 태그 구문 뿐만 아니라 PHP 처리 속도 향상이라는 장점을 얻는다. 각 템플릿이 처음 호출될 때 컴파일이 이루어지며, 이후로는 컴파일된 버전이 사용된다. 이 모든 작업을 스마티에서 처리하므로, 템플릿 디자이너는 그저 스마티 템플릿을 수정하면 될 뿐, 컴파일된 버전을 관리할 필요가 없어진다. 따라서 템플릿을 유지보수하기가 쉬워질뿐만 아니라, 처리 속도 또한 상당히 빨라진다. 컴파일된 버전 또한 PHP 코드이므로 APC나 ZendCache와 같은 op-code 가속기는 컴파일된 스크립트에도 여전히 적용할 수 있다.

템플릿 상속

스마티 버전 3에서는 템플릿 상속 기능이 추가되었는데, 이는 스마티의 강력한 기능 중 하나이다. 템플릿 상속이 없었을 때에는 헤더(header) 템플릿, 푸터(footer) 템플릿과 같은 단위로 템플릿을 관리했다. 이러한 구조화는 그 자체로 많은 문제점을 낳았으며, 페이지 단위로 헤더/푸터에 컨텐츠를 관리하는 마구잡이 방식이 나타났다. 템플릿 상속을 사용하면 다른 템플릿을 포함하는 대신에, 템플릿을 하나의 페이지로 관리할 수 있다. 그리고 템플릿을 상속받고, 상속받은 템플릿 내에서 컨텐츠 블록을 조작할 수 있다. 이를 통해 템플릿을 더 쉽게 이해할 수 있게 되었고, 쉽고 효율적으로 관리할 수 있다. 더 자세한 내용은 템플릿 상속을 살펴보라.

XML/XSLT 구문을 사용하지 않는 이유는?

여기에는 몇가지 근거가 있다. 먼저, 스마티는 XML/HTML 기반 템플릿이 제공하지 못하는 일들을 할 수 있다. 예를 들어 이메일, 자바스크립트, CSV, PDF 문서 등을 생성할 수 있다. 둘째, XML/XSLT 구문은 PHP 코드보다도 장황하며, 실수하기도 쉽다. XML/XSLT 구문은 컴퓨터가 보기에는 완벽하지만, 사람이 보기에는 끔찍한 구문이다. 스마티는 사람이 쉽게 읽을 수 있고, 이해할 수 있으며 관리하기 위해 만들어졌다.

템플릿 보안

스마티는 PHP 코드를 분리할 수 있지만, 여러분이 원하는 방식으로 사용할 수 있다. 템플릿 보안은 PHP에 제한을 가한다. 이는 써드 파티 편집 템플릿을 사용하고 있고, PHP와 스마티의 완전한 기능을 모두 허락하고 싶지 않은 경우에 유용하다.

또다른 템플릿 엔진들..
스마티는 “프로그래밍코드와 프레젠테이션의 분리” 철학을 따르는 유일한 템플릿 엔진은 아니다. 예를 들어 파이썬에서는 장고(Django) 템플릿, 치타(Cheetah) 템플릿과 같이 동일한 원칙을 따르는 템플릿 엔진이 만들어졌다.
주석: 파이썬과 같은 언어는 태생적으로 HTML과 섞어 쓰지는 않으므로, 프로그래밍 코드와 외부 코드를 적절히 분리해서 사용할 수 있는 장점이 있다. 하지만 파이썬과 HTML을 섞어서 쓸 수 있는 라이브러리가 존재한다. 하지만 이러한 방식은 피해야 한다.

스마티가 지원하지 못하는 것들
스마티는 어플리케이션 개발 프레임워크는 아니다. 스마티는 MVC가 아니다. 스마티는 Zend 프레임워크, CodeIgniter, CakgePHP와 같이 PHP 개발을 위한 어플리케이션 프레임워크가 아니다.

스마티는 템플릿 엔진이며, 어플리케이션 내에서 V(iew) 컴포넌트로만 동작한다. 스마티는 위에서 언급한 모든 프레임워크가 쉽게 결합하여, 뷰 컴포턴트로 사용할 수 있다. 물론 다른 소프트웨어와 마찬가지로, 스마티를 배우기 위해선 노력이 든다. 스마티 자체가 좋은 어플리케이션 설계 또는 적절한 프레젠테이션 분리를 보장하는 것은 아니다. 이는 컴포넌트 개발자와 웹 디자이너가 여전히 고민해야할 요소다.

내게 정말 스마티가 필요한가?

스마티를 모든 경우에 사용할 수 있는 것은 아니다. 따라서 스마티가 당신에게 정말로 적합한지 확인하는 과정이 매우 중요하다. 아래와 같은 질문을 스스로에게 물어보라.
• 템플릿 구문(Template Syntax)
PHP와 HTML 태그를 섞어서 쓰더라도 만족하는가? 웹 디자이너가 PHP에 익숙한가? 웹 디자이너가 프레젠테이션에 특화된 태그 기반의 구문을 더 선호하는가? 얼마간 스마티와 PHP를 함께 사용해 보면, 정답을 찾을 수 있을 것이다.
• 비즈니스 상황(Business Case)
템플릿을 PHP로부터 분리해야 하는 요구사항이 있는가? 믿을만하지 않은 써드 파티에서 만든 편집 텝플릿을 사용하고 있고, PHP 코드의 완전한 기능을 해당 편집 템플릿에 허락하고 싶지 않은가? 템플릿에서 사용할 수 있는 것과 사용할 수 없는 것을 프로그래밍적으로 제어할 필요가 있는가? 스마티는 이러한 기능을 제공하기 위해 만들어졌다.
• 기능 집합(Function Set)
캐싱, 템플릿 상속, 플러그인 아키텍처와 같은 스마티 기능을 사용하면 해당 코드를 직접 개발하지 않아도 되므로 개발 사이클을 단축시킬 수 있는가? 사용하려는 코드베이스 또는 프레임워크에서 프레젠테이션 컴포넌트를 제공하는가?
또한 스마티 웹사이트에서 유스케이스와 워크플로우를 살펴보라.

스마티를 사용하는 사이트들
스마티 웹 사이트에는 매일 유니크한 수만명의 사용자가 방문하며, 그들 중 대다수는 문서를 읽으려는 개발자들이다. 잘 알려진 PHP 프로젝트 중 많은 수가 스마티를 활용한다. 예를 들어 XOOPS CMS, CMS Made SImple, Tiki CMS/Groupware 등이 있다.

요약

스마티를 간단한 웹사이트를 위해서 사용하든지 아니면 대규모의 기업 솔루션을 개발하기 위해 사용하든지 관계없이 여러분이 필요한 것들을 만족시켜줄 것이다. 스마티를 선택해야만 하는 이유에는 여러가지가 있다.
• PHP와 HTML/CSS는 반드시 분리해야 한다.
• 쉽게 구조화하고 관리가 편리하다.
• 서드 파티 템플릿 접근에 대한 보안
• 완전한 기능을 제공하며, 필요에 따라 쉽게 확장 가능하다.
• 대규모 사용자를 기반으로 한다.
• 상용의 경우 LGPL 라이선스
• 100% 무료로 사용할 수 있는 오픈 소스 프로젝트