15
Billy Hollis
Elysian Consulting
2004년 3월 24일
요약: 최근 수 년간 웹 응용 프로그램에 지대한 관심이 모아지면서, 클라이언트의 향상과 함께 클라이언트 쪽 개발에 대해 다시 연구해야 할 필요성이 대두되었습니다. Microsoft 지역 담당 이사들이 저술하는 이 새 칼럼 .NET in the Real World에서 Billy Hollis가 스마트 클라이언트에 대해 설명하고 현재 스마트 클라이언트를 사용하여 응용 프로그램을 빌드하는 방법을 설명합니다(6페이지/인쇄 페이지 기준).
관련 서적
오래 전에는 스마트 클라이언트를 메인프레임이라고 불렀습니다. 나이가 많지 않은 사용자는 이러한 시기를 기억하지 못할 수도 있습니다. 이 메인프레임의 작동 방식에 대해 간단히 살펴보겠습니다. 당시, 거대한 메인프레임 시스템은 모든 처리를 수행했습니다. 이 시스템은 정보 페이지를 어셈블하여 터미널이라는 장치로 보냈습니다. 가장 일반적인 터미널 유형은 3270이었습니다.
터미널은 단순한 장치라고 할 수 있었습니다. 그 처리 기능에 대해서는 얘기할 것이 없습니다. 사용자가 터미널로 수행할 수 있는 작업이라고는 데이터 필드를 채우고 화면을 탐색하는 것뿐이었습니다.
데이터 페이지 작업을 마친 후 터미널에서 단추를 누르면 페이지의 정보가 다시 메인프레임으로 전송됩니다. 그러면 메인프레임에서는 페이지의 정보를 받아 처리하고 새 페이지로 내보낼 수 있도록 준비합니다.
이후 PC가 출현하여 네트워크에 연결된 이후에야 메인프레임보다 효과적인 작업을 할 수 있게 되었습니다. PC의 처리 기능을 사용하여 사용자 인터페이스를 보다 지능적으로 만들고 사용자의 작업 방식에 대해 기억하게 만들 수 있습니다. 그러면 사용자가 더욱 효율적이고 생산적으로 작업할 수 있습니다.
이렇게 새로운 시스템 유형이 탄생했습니다. 이 시스템의 가장 큰 장점은 사용자의 PC와 거대한 중앙 컴퓨터에 효과적으로 작업을 배포할 수 있다는 점입니다. 이러한 점으로 인해 서버라는 새 이름이 생겼습니다. 이 클라이언트-서버 시스템은 PC와 대형 중앙 시스템에서 각각 최상의 작업을 수행할 수 있게 합니다. 클라이언트-서버는 대부분의 메인프레임을 대신하게 되었고 사용자들도 이 클라이언트-서버를 더 선호하게 되었습니다. 사용자가 생산적이고 즐거운 작업을 할 수 있는 길이 열린 것입니다.
그런 다음 인터넷이 출현했습니다. 처음에 인터넷은 단지 정적 하이퍼링크 페이지를 검색하는 데만 사용되었습니다. 그러나 젊은 층 사용자들이 인터넷을 통해 많은 작업을 수행할 수 있다는 평가를 보이기 시작했습니다. 즉, 인터넷에서 응용 프로그램을 실행하고 모든 처리를 수행하는 대규모 중앙 웹 서버를 사용할 수 있습니다. 또한 페이지를 사용자에게 전송하면 페이지를 받은 사용자는 브라우저에서 이 페이지를 보면서 탐색하거나 데이터를 입력할 수 있습니다. 그런 다음 사용자가 단추를 눌러 페이지의 정보를 다시 대규모 시스템으로 전송하면, 이 시스템에서는 해당 정보를 처리하고 다시 새 페이지를 전송합니다. 이와 같은 모든 작업이 인터넷을 통해 가능해진 것입니다.
브라우저에는 지능적 기능이 많지 않았습니다. 즉, 브라우저는 PC에서 이 브라우저를 실행하는 것 외에는 아무것도 수행하지 않는 "씬 클라이언트"로 간주되었습니다. 그리하여 20년 전의 메인프레임보다 훨씬 많은 처리 기능을 갖춘 PC가 아날로그 방식 3270 터미널로 퇴화되었습니다.
이같이 엄청난 수준의 역행이 발생하게 된 이유는, 다른 대부분의 분야에서와 마찬가지로 "비용" 때문이었습니다. Microsoft에서는 브라우저 기반 시스템을 통해 처음으로 전 세계 사용자가 Microsoft 시스템에 액세스할 수 있게 했으며, 이는 큰 발전이었습니다. 새로운 사용자가 시스템에 액세스할 수 있게 하는 데는 기본적으로 비용이 전혀 들지 않았습니다.
"리치 클라이언트" 또는 "스마트 클라이언트"라는 대안을 위해서는 일부 특수 소프트웨어를 사용자 시스템에 설치해야 했습니다. DOS 시기에는 이 작업이 쉬웠습니다. 소프트웨어를 복사해 놓기만 하면 실행되었습니다. 그러나 사실상 브라우저와 거의 같은 시기에 COM이 나타났고 DLL이라는 용어가 대두되었습니다. 그리하여 우리는 소프트웨어를 사용자 컴퓨터에서 실행하는 것을 포기했으며, 다른 방법을 수행할 여력이 없었기 때문에 브라우저만을 사용했습니다. 아무 것도 없는 것보다는 무엇인가 있는 게 나았기 때문이죠. 성능이 좀 떨어지더라도 수행할 여력이 되는 대안을 실행하는 편이 아무 것도 실행하지 않는 것보다는 낫다는 뜻입니다.
그러나 여기서 발상을 전환해 보겠습니다. 소프트웨어를 사용자 시스템에 배포하는 비용이 브라우저를 사용할 때처럼 비용이 전혀 들지 않는 것에 아주 가까울 정도로 저렴하게 줄어든다고 가정해 봅시다. 그러면 어떤 현상이 발생할까요?
First Law of Software Development에서 Billy가 언급하는 의견은 다음과 같습니다. 사용자 수가 프로그래머 및 기술 지원 담당자 수보다 많습니다. 사용자가 있기 때문에 우리 시스템이 존재하는 것입니다. 사용자가 지능적인 응용 프로그램 소프트웨어 인터페이스를 사용할 수 있게 되어 작업을 보다 효율적으로 수행할 수 있음을 알게 된다면, 불편한 인터페이스를 더 이상 사용하지 않게 될 것입니다. 또한, 응용 프로그램 인터페이스를 위해서가 아니라 하이퍼링크 페이지를 검색하기 위해 디자인된 프로토콜을 사용하여 만들어진 페이지에 만족하지 못할 것입니다. 금방 불편이나 싫증을 느끼게 될 것이라는 의미입니다.
가능성을 고려해 보십시오. 시스템에 천 명의 운영자가 있을 경우, 스마트 클라이언트 소프트웨어를 통해 운영자 작업 효율성이 단 5% 정도만 상승한다 해도 비용 절감 효과는 엄청날 수 있습니다. 직원 한 명당 비용이 5만 달러라고 가정할 때, 천 명의 운영자에 대해 생산성이 5% 향상될 경우 50명의 운영자에 해당하는 비용인 2백 5십만 달러가 절약됩니다. 또한 여기에는 보다 낮은 학습 비용과 오류 비율, 사용자의 혼란과 스트레스 등의 감소 및 기타 스마트 클라이언트 소프트웨어의 제품별 잠재 감소 비용이 포함되어 있지 않습니다. 더구나, 상승률 5%는 매우 낮게 잡은 수치입니다. 작업에 따라 10%에서 20%까지 생산성이 향상되는 경우도 드물지 않습니다.
선택
이 분석이 정확하다면 소프트웨어 개발 및 IT 분야의 의사 결정권자들이 선택을 하는 데 있어 큰 영향을 미칠 수 있을 것으로 보입니다. 어렵지 않게 스마트 클라이언트를 받아들이는 사용자도 있겠지만, 거부감을 느끼는 사용자도 있을 것입니다. 또한 선택한 전략이 득이 될 수도 있고 실이 될 수도 있습니다.
브라우저 기반 소프트웨어에 크게 의존하는 1990년대 방식을 고수할 수도 있습니다. 속해 있는 업계 및 조직이 신기술로 전환하는 속도에 따라, 이러한 전략을 문제 없이 채택할 수도 있습니다. 그러나 기술이 경쟁력을 좌우하는 빠르게 변화하는 업계에서 이러한 전략은 업무 자체에 큰 위험을 초래할 수 있습니다. 조직의 기술 관련 실무 담당자가 "이 브라우저 기반 방식은 쓸모가 없습니다. 사용자에게 인기도 없을 뿐더러 사용자의 작업 속도도 떨어뜨리고 있습니다. 사용자가 작업을 보다 신속하고 효율적으로 수행할 수 있도록 하고 회사의 비용을 크게 줄여 주는 지능적인 사용자 인터페이스가 포함된 다른 시스템으로 바꾸는 것이 좋겠습니다. 이미 늦었는지도 모르겠군요. 지금 당장 바꿔야겠습니다."라고 할 수도 있고, "부서 관리자를 변경하기로 결정했습니다"라고 말하는 더 나쁜 상황이 발생할 수도 있습니다.
이러한 상황을 원하지는 않으시겠죠? 그렇다면 스마트 클라이언트 사용을 고려해 보십시오. 먼저, 새로 작성하는 응용 프로그램을 사용할 500명의 사용자가 구식 브라우저 인터페이스를 사용하도록 할 것인지 아니면 새롭고 뛰어난 지능적 사용자 인터페이스를 사용하도록 할 것인지를 결정해야 합니다. 이 결정을 통해 수백 또는 수천 사용자의 생산성을 향상시키고 비용을 크게 절감할 수 있는 소프트웨어를 만들 수도 있습니다. 당신이 만든 인터넷 응용 프로그램에 대해 사용자들이 찬사를 보낼 수도 있다는 것입니다.
시작하기
현명한 선택을 하려면 스마트 클라이언트 개발의 장단점에 대해 파악해야 합니다. 스마트 클라이언트 아키텍처가 작동하게 만드는 데는 다음과 같은 4가지 주요 기술이 필요합니다.
- 지능적 클라이언트 소프트웨어를 만들기 위한 폼 패키지
- 로컬 네트워크 또는 인터넷에서 스마트 클라이언트와 중앙 서버 간에 데이터를 교환하기 위한 데이터 전송 기술
- 인터넷에서 다양한 경우에 스마트 클라이언트 소프트웨어를 클라이언트 컴퓨터에 배포하기 위한 수단
- 악의적인 액세스로부터 시스템을 보호하기 위한 보안 기술
현재, 이러한 기능을 모두 사용할 수 있는 플랫폼은 Microsoft .NET Framework입니다. Microsoft .NET Framework이 유일한 분산 스마트 클라이언트 시스템용 플랫폼은 아니지만, Java 등의 다른 플랫폼보다 크게 앞서 있습니다. 위의 각 분야에서 .NET 기능을 살펴보고, .NET이 다른 플랫폼에 비해 앞서 있는 이유를 알아보겠습니다.
클라이언트의 폼
.NET Framework에는 현재 사용 가능한 가장 발전된 폼 엔진 중 하나인 Microsoft Windows Forms가 포함되어 있습니다. 이 폼은 완전한 객체 지향이며 Microsoft 및 타사의 다양한 비주얼 컨트롤을 포함합니다. 또한 Microsoft Visual Studio 개발 환경에는 뛰어난 비주얼 디자이너가 포함되어 있으므로 Windows Forms 인터페이스를 신속하게 만들 수 있습니다.
Windows Forms의 이벤트 중심 방식과 상태 정보를 필요한 만큼 로컬에 저장할 수 있는 기능을 사용하면 사용자 인터페이스의 응답 능력을 크게 향상시킬 수 있습니다. 파생 데이터 입력 작업에는 해당 작업을 위해 특별히 만들어진 인터페이스를 사용할 수 있습니다. 정교한 데이터 유효성 검사는 데이터가 정확한지 확인하기 위해 페이지를 다시 로드할 필요 없이 처음부터 올바른 데이터를 사용할 수 있게 합니다. 물론 브라우저에서도 이러한 작업 중 일부를 수행할 수 있습니다. 그러나 이러한 작업을 수행하는 데는 불필요한 다량의 프로그래밍 작업이 수반됩니다.
Windows Forms 인터페이스에는 자습서 창, 도구 설명, 투명한 도움말 폼, 사용자가 해당 동작을 수행할 수 있도록 하는 동적 컨트롤 등이 포함될 수 있습니다. 또한 Windows Forms 인터페이스는 일반적으로 해당 웹 페이지보다 빠르게 개발할 수 있습니다.
Microsoft에서는 이러한 기술 영역에 많은 투자를 하고 있습니다. 이미 차세대 UI 기술이 발표되었습니다. 이 프로젝트의 코드 이름은 "Avalon"이며, 현재 개발 중에 있는 다음 Microsoft Windows 릴리스(코드 이름 "Longhorn")의 일부입니다. Avalon에는 브라우저에서는 사실상 불가능한 일부 새로운 사용자 상호 작용 방식을 포함하여 사용자 인터페이스의 응답 능력을 향상시키는 많은 기능이 추가될 예정입니다.
이러한 기술을 활용하려면 개발자는 사용자 인터페이스 디자인 원칙에 대해 보다 자세히 파악해야 합니다. 지금까지 단순히 브라우저 기반 프로그래밍만 수행한 개발자는 UI 디자인에 대해 익혀야 할 사항이 많다는 사실을 모르고 있을 수도 있습니다. 응답 능력이 뛰어나고 지능적인 인터페이스를 작성하는 방법을 알아야 시스템에 이러한 인터페이스를 포함할 수 있습니다.
여기에는 한 가지 제한 사항이 있습니다. Windows Forms는 .NET Framework의 일부이기 때문에 Windows 플랫폼에서만 사용할 수 있습니다. 그러나 일반적으로 그러하듯이 조직에서 클라이언트 워크스테이션에 대해 Microsoft Windows Server System™을 표준으로 지정한 경우 이러한 사항은 문제가 되지 않습니다.
데이터를 필요로 하는 응용 프로그램
대부분의 회사 및 상용 응용 프로그램은 일반적으로 일부 중앙 서버에 저장되어 있는 데이터를 조작합니다. 실용적인 스마트 클라이언트 응용 프로그램이라면 서버에서 클라이언트로 데이터를 가져와서 클라이언트에서 데이터를 변경한 다음 다시 데이터를 서버로 보낼 수 있어야 합니다.
Microsoft의 최신 데이터 액세스 기술인 Microsoft ADO.NET은 바로 이러한 시나리오를 위해 디자인되었습니다. 이전의 데이터 액세스 모델과는 달리, ADO.NET은 분산적으로 사용하기 위해 만들어졌습니다. 서버에서 데이터의 XML 기반 컨테이너를 만들어 클라이언트로 전송할 수 있습니다. 클라이언트는 컨테이너를 통해 서버에 대한 연결을 유지하지 않은 상태로 데이터에 대한 작업을 수행하여 데이터를 변경 및 추가한 다음 컨테이너를 다시 서버로 보낼 수 있습니다.
클라이언트와 서버 컴퓨터 간에 데이터를 실제로 전송하는 데 사용할 수 있는 주요 기술에는 두 가지가 있습니다. 하나는 웹 서비스입니다. 웹 서비스의 장점에는 구현 및 구성의 용이성, 많은 종류의 서버에 대한 상호 호환성 등이 있습니다. 적합한 데이터 컨테이너를 만드는 데는 약간의 작업이 더 필요하지만 웹 서비스는 Microsoft 서버가 아닌 서버와도 호환될 수 있습니다.
사용자 응용 프로그램에 관련된 모든 시스템에서 Microsoft .NET을 실행할 수 있는 경우에는 .NET 원격 기술을 사용할 수도 있습니다. 이 기술에는 성능 및 보안상의 장점이 있지만, 구성하기는 더 어렵습니다. 내부 사용자를 위한 대규모 스마트 클라이언트 시스템은 종종 원격 기술을 사용하지만 조직 외부에 있는 사용자가 사용하는 시스템은 웹 서비스를 많이 사용합니다.
두 가지 경우에서 모두 스마트 클라이언트 응용 프로그램은 브라우저 기반 시스템보다 훨씬 지능적으로 데이터를 처리할 수 있습니다. 예를 들어, 스마트 클라이언트에서 서버와의 연결이 끊길 경우 서버를 다시 사용할 수 있을 때까지 데이터의 로컬 복사본을 유지할 수 있습니다. 스마트 클라이언트 응용 프로그램은 온라인 및 오프라인 시나리오에 맞게 해당 동작을 동적으로 조정할 수 있습니다.
낮은 배포 비용
처음에 글을 시작할 때 스마트 클라이언트 시스템의 배포 비용을 브라우저 기반 시스템만큼 저렴하거나 거의 비슷하게 만드는 경우의 결과에 대해 언급했습니다. 브라우저 기반 응용 프로그램은 각 추가 사용자에 대해서는 사실상 배포 비용이 들지 않으므로, 이 응용 프로그램보다 배포 비용을 훨씬 저렴하게 만들기는 어렵습니다. 그러나 경쟁력을 갖출 정도로 스마트 클라이언트 배포 비용을 줄일 수는 있습니다. 또한 스마트 클라이언트를 사용하면 생산성 향상을 통해 많은 비용을 절약하게 될 수도 있으므로 약간의 추가 배포 비용은 경제적으로 무리가 없습니다.
배포 비용을 줄이는 주요 기술은 .NET Framework의 복사 및 실행(copy-and-run) 기능입니다. COM에서처럼 시스템 구성 요소를 등록하기 위한 복잡한 절차가 필요하지 않습니다. 구성 요소를 디스크에 복사하기만 하면 나머지 작업은 Framework에서 수행합니다. 또한 여러 DLL 버전을 함께 실행할 수 있으므로 호환되지 않는 DLL 문제가 없어집니다.
제한된 형식의 자동 인터넷 배포가 이미 .NET Framework에 포함되어 있으며, 보다 고급 버전인 코드 이름 "ClickOnce"가 다음 버전에 포함될 예정입니다. 또한 복사 및 실행(copy-and-run) 방법을 활용하여 자체 업데이트 응용 프로그램을 쉽고 저렴하게 만들 수 있는 사용자 지정 배포 시스템을 간편하게 만들 수 있습니다.
브라우저 기반 응용 프로그램을 실행하려면 브라우저를 클라이언트 시스템에 설치해야 하는 것과 마찬가지로, .NET 기반 스마트 클라이언트를 실행하려면 .NET Framework를 클라이언트 컴퓨터에 설치해야 합니다. 현재 Windows XP, Windows 2000, Windows 98/Me 등 대부분의 클라이언트 컴퓨터에서 사용하는 운영 체제에서는 .NET Framework가 자동으로 설치되지 않기 때문에 추가 작업이 필요합니다. 그러나 이러한 운영 체제에서 .NET Framework를 무료로 설치할 수 있습니다. Microsoft에서는 이후의 운영 체제 제품에 .NET Framework를 포함시킬 예정이므로 앞으로 새 버전의 운영 체제가 출시되면 .NET Framework를 쉽게 접하게 될 것입니다. 사실 Microsoft에서는 이미 Microsoft Windows Server™ 2003에 .NET Framework를 포함시켰습니다.
완벽한 보안
지난 몇 년간 사용자들은 인터넷에 악의적인 사용자들이 많다는 사실을 알게 되었으며, 그리하여 시스템의 보안을 더욱 강력하게 유지하고자 했습니다. 그러나 분산 스마트 클라이언트 시스템에는 확실히 새 보안 기능이 필요합니다.
다행히도 .NET Framework는 엄격한 보안 원칙 하에 디자인되었습니다. 버퍼 오버런과 같은 취약점을 제거하는 것 외에 코드 액세스 보안이라는 새로운 형식의 보안 기능이 추가되었습니다. 이 기능은 코드 출처, 코드 작성자 등 코드에 대한 정보를 기반으로 코드에 보안 권한을 부여합니다. 이 보안 기능은 일반 사용자 기반 보안을 기준으로 하며, 코드를 다시 한 번 보호해 주는 역할을 합니다.
클라이언트와 서버 시스템 간의 인터페이스를 보다 주의 깊게 제어할 수 있으며 시스템의 실행 가능 부분에서 필요한 권한만을 받을 수 있기 때문에 적절히 디자인된 스마트 클라이언트 시스템은 일반 브라우저 기반 시스템보다 안전하다고 할 수 있습니다. 그러나 이러한 고급 보안을 디자인하려면 새로운 기술과 개념을 배워야 합니다.
작업 계획
스마트 클라이언트로의 전환을 서두를 필요는 없습니다. 앞으로 2년 내라면 괜찮습니다. 물론, 그 전에 경쟁사가 먼저 전환하지 않아야겠지만요. 사용자는 아직 이러한 실정을 잘 파악하지 못하고 있습니다. 또한 적절한 비용으로 배포하기 위해서는 .NET Framework를 클라이언트 컴퓨터를 설치해야 합니다.
그러나 이는 일시적일 뿐입니다. 앞으로 몇 년이 지나면 스마트 클라이언트 응용 프로그램이 많은 브라우저 기반 응용 프로그램을 대신하게 될 것이라고 확신합니다. 저만 해도 이미 5명의 고객이 스마트 클라이언트 응용 프로그램으로 전환하겠다고 했으며 그 결과에 대해 큰 기대를 하고 있습니다.
그러나 전환 시 전혀 부담이 없는 것은 아닙니다. 개발자는 새롭게 배포된 아키텍처와 새 기술을 배워야 합니다. 또한 대부분의 경우 개체 지향 개발 및 사용자 인터페이스 디자인에 대해 익숙해져야 합니다.
브라우저 기반 개발을 배우는 데 5년이라는 시간을 투자한 개발자는 변경하기를 원하지 않을 수 있습니다. 그들은 그러한 시간을 거쳐 이미 당대 최고의 개발자가 되었기 때문입니다. 그러나 모든 기술에는 전성기와 쇠퇴기가 있으며, 보다 새로운 기술로 대체됩니다. 오랫동안 특정 시나리오에 사용된 브라우저 기반 응용 프로그램에 대해 살펴보면서 브라우저 기반 개발의 전성기는 이미 지났다는 확신을 가지게 되었습니다. 어떤 기술이 최신 상태에서 구식이 되는 데는 시간이 걸릴 수 있지만, 이는 시간이 지남에 따라 반드시 나타나는 현상이기 때문입니다. 스마트 클라이언트를 사용할 수 있도록 준비하십시오!
관련 서적
Windows Forms Programming in C# 
.NET in the Real World
스마티 기본 문법
작성: pinkhare(분홍토끼) in GTport
스마티 템플릿 태그는 전부 구획 문자로 에워싸이게 되는데, 구획 문자의 기본 값은 {, } 로 표현되며 다른 것으로 사용할 수도 있습니다.
기본 구획 문자를 사용할 경우는 구획 문자로 둘러싸이지 않은 내용들은 전부 고정적인 내용으로 출력되거나 있는 그대로 표현됩니다.
스마티는 템플릿 태그를 읽어들이게 되면, 알맞는 값으로 변환하여 보여줍니다.
1) 스마티 주석 처리 방법
- 중괄호'{}' 안에 애스터리스크(*)로 내용을 감싸면 됩니다.
예제) {* 저는 주석이에요~ *}
- HTML의 주석인 '<!-- -->'은 최종 결과물에 표시가 되지만, 스마티 주석은 최종 결과물에는 출력되지 않습니다.
예제)
{*
개발자 주석: $includeFile은 foo.php 스크립트 안에 선언되어있다.
(이것은 브라우저로 전송되지 않는 주석이므로, 이용자들이 볼 수 없다)
*}
<!-- 이 HTML 주석은 브라우저로 전송되어 이용자들이 볼 수 있다 -->
{include file=$includeFile}
2) 스마티 변수
스마티에서 템플릿 변수는 PHP와 마찬가지로 변수명 앞에 달러표시($)가 붙습니다. 변수명에는 숫자 및 언더스코어를 포함할 수 있습니다.
계수적/비계수적으로 표현되는 배열들을 참조할 수 있습니다. 객체 프로퍼티 및 메소드를 참조할 수도 있습니다.
환경 파일 변수는 앞에 달러표시를 붙이지 않고, 그 대신 해쉬마크(#: 샵 or 잡동사니 부호)를 둘러서 표현하든지 특수 $smarty.config 변수로 표현할 수 있습니다.
예제)
{$foo[4]} <-- 0-인덱스 배열의 5번째 엘리먼트 출력
{$foo.bar} <-- display the "bar" key value of an array, similar to PHP $foo['bar']
{$foo.$bar} <-- display variable key value of an array, similar to PHP $foo[$bar]
{$foo->bar} <-- display the object property "bar"
{$foo->bar()} <-- display the return value of object method "bar"
{#foo#} <-- display the config file variable "foo"
{$smarty.config.foo} <-- synonym for {#foo#}
{$foo[bar]} <-- syntax only valid in a section loop, see {section}
{assign var=foo value="baa"}{$foo} <-- displays "baa", see {assign}
다음과 같이 여러가지 조합도 가능합니다 ;
{$foo.bar.baz}
{$foo.$bar.$baz}
{$foo[4].baz}
{$foo[4].$baz}
{$foo.bar.baz[4]}
{$foo->bar($baz,2,$bar)} <-- passing parameters
{"foo"} <-- static values are allowed
# 추후 연재될 스마티 예약 변수 및 환경(설정) 변수 참조.
3) 함수
스마티 태그는 변수를 출력하거나 함수를 호출합니다.
함수는 그 함수 및 애트리뷰트를 {함수명 애트리뷰트1="값" 애트리뷰트2="값"}과 같이 구획 문자로 둘러쌈으로써 처리되어 출력됩니다.
예제) 함수 구문
{include file="header.tpl"}
{if $highlight_name}
Welcome, <font color="{#fontColor#}">{$name}!</font>
{else}
Welcome, {$name}!
{/if}
{include file="footer.tpl"}
템플릿에서 내장함수와 사용자함수는 똑같은 구문 체계를 사용합니다.
내장함수는 스마티 내부 처리를 담당하며, 수정이 불가능 합니다.
{if}, {section}, {strip} 등..
사용자함수는 플러그인을 이용하여 구현되는 부가 함수입니다. 함수 사용자의 편의대로 고쳐서 사용할 수가 있고 새로운 기능을 추가할 수도 있습니다.
{html_options}, {popup} 등..
4) 애트리뷰트
대부분의 함수는 자신의 기능을 특화하고 수정해주는 애트리뷰트들을 가집니다.
HTML의 애트리뷰트와 거의 흡사합니다. 고정적 값들은 굳이 따옴표 처리할 필요가 없지만, 문자열을 표현할 때 따옴표 처리를 하는게 좋습니다. 변수 사용시에는 따옴표 처리를 하면 안됩니다.
논리(boolean)값 (true, false)을 요하는 애트리뷰트도 있는데, 참과 거짓의 경우 각각
- 참 : true, on, yes
- 거짓 : false, off, no
과 같이 따옴표 없이 적어주면 됩니다.
예제) 함수 애트리뷰트 문법
{include file='header.tpl' attrib_name='attrib value'} --> 문자열
{include file=$includeFile} --> 변수명은 따옴표 없음
{include file=#includeFile# title='Smarty is cool'}
{html_select_date display_days=yes}
{mailto address='smarty@example.com'} --> 메일주소도 문자열이므로
<select name='company_id'>
{html_options options=$companies selected=$company_id}
</select>
5) 큰 따옴표로 묶인 삽입 변수들
스마티는 큰 따옴표 안에 선언된 삽입 변수를 인식합니다. 단, 그 변수는 숫자, 글자, 언더스코어, 대괄호([]) 만으로 이루어져야 합니다. 혹시 마침표, 객체 참조 등의 기타 문자들을 사용하려면 변수명을 역따옴표(``)로 묶어야 합니다. 변경자는 따옴표 안에 삽입할 수 없고, 따옴표의 바깥에 적용해야 합니다.
예제) 삽입 따옴표 문법
{func var="test $foo test"}
{func var="test $foo_bar test"}
{func var="test $foo[0] test"}
{func var="test $foo[bar] test"}
{func var="test $foo.bar test"} --> $foo.bar 를 참조하지 않고 $foo 를 참조함 (역따옴표 없는 마침표는 인식 안함)
{func var="test `$foo.bar` test"} --> 변수명에 마침표가 사용되어, 역따옴표로 묶음
{func var="test `$foo.bar` test"|escape} --> 변경자는 따옴표의 바깥에 적어주었다
사용 예제:
{include file="subdir/$tpl_name.tpl"} <-- will replace $tpl_name with value
{cycle values="one,two,`$smarty.config.myval`"} <-- must have backticks
# 추후 연재될 이스케이프 문자 참조.
6) 연산
변수값에 직접 연산을 적용할 수 있습니다.
예제) 연산 예제들
{$foo*$bar}
{* 좀 더 복잡한 예제들 *}
{$foo->bar-$bar[1]*$baz->foo->bar()-3*7}
{if ($foo+$bar.test%$baz*134232+10+$b+10)}
{$foo|truncate:"`$fooTruncCount/$barTruncFactor-1`"}
{assign var="foo" value="`$foo+$bar`"}
7) 스마티 구문 분석(파싱) 탈피
일부 스마티 문법이 적용되지 않는게 좋거나 적용되지 말아야 하는 부분이 있습니다. 즉, 스마티 문법과 다른 방식으로 판독(구문 분석)이 되어야 하는 부분이 존재합니다. 일례로 자바스크립트 및 CSS 코드를 템플릿에 삽입하는 경우가 그것이죠. 그러한 언어들이 스마티의 기본 구획문자를 사용하기 때문에 문제가 발생하게 됩니다.
이걸 완전히 피하기 위한 가장 단순한 방법은 자바스크립트와 CSS 코드를 해당하는 포맷의 각각의 파일로 분리하고 그 파일들에 접근하는 데 표준 HTML 방식을 사용하는 것입니다.
있는 그대로의 내용을 담기 위해서 {literal} ... {/literal} 블록을 이용할 수 있습니다.
HTML 개체 사용과 비슷하게 현재의 구획문자를 보여주는 데 {Idelim},{rdelim} 또는 {$smarty.Idelim}을 사용할 수 있습니다.
스마티의 $left_delimiter 와 $right_delimilter를 변경하는 것이 때때로 편리합니다.
예제) 구획문자 변경 예제
$smarty = new Smarty;
$smarty->left_delimiter = '<!--{';
$smarty->right_delimiter = '}-->';
$smarty->assign('foo', 'bar');
$smarty->display('example.tpl');
?>
example.tpl 에는:
<script language="javascript">
var foo = <!--{$foo}-->;
function dosomething() {
alert("foo is " + foo);
}
dosomething();
</script>
# 추후 연재될 이스케이프 변경자를 참조하세요.
03
스마티 설치하기 - v2.6.1.1 기준
출처: http://smarty.php.net/whyuse.php
번역: pinkhare(분홍토끼) in GTport
시스템 요구 사항 : PHP 4.0.6 이후 버전이 운용되는 웹 서버가 필요합니다.
기본 설치
배포된 /libs/ 서브디렉토리에 있는 스마티 라이브러리 파일들을 인스톨 합니다. 이 파일들은 여러분이 임의로 수정해서는 안되는 PHP 파일들입니다. 그 파일들은 전체 응용프로그램 간에 공유되고 여러분이 새 버전의 스마티로 업그레이드할 때에만 갱신됩니다.
|
예제 2-3. SMARTY_DIR 상수의 수동 설정
|
|
예제 2-5. 라이브러리 디렉토리를 PHP include_path에 추가
|
라이브러리 파일이 제 위치에 놓였으니, 이제는 여러분 응용프로그램에 대한 스마티 디렉토리를 설정할 시간이로군요.
스마티는 기본값 이름을 가진 'templates/', 'templates_c/', 'configs/', 'cache/' 이렇게 4개의 디렉토리가 필요합니다.
각 디렉토리는 스마티 클래스 프로퍼티인 $template_dir, $compile_dir, $config_dir, $cache_dir에 의해서 개별적으로 정의될 수 있으며, 스마티를 사용하게 될 각각의 응용프로그램에 대해 이 디렉토리들을 따로 분리된 집합으로 설정하도록 강력히 권장합니다.
여러분의 웹 서버 문서의 루트 위치를 확인하십시오. 예제에서는, 문서 루트가 /web/www.example.com/docs/ 로 되어있습니다. 스마티 라이브러리만이 스마티 디렉토리들에 접근하며, 웹 브라우저가 직접 접근할 수 없습니다. 따라서 보안 우려를 피하기 위해, 이 디렉토리들을 문서 루트의 바깥에 두기를 권장합니다.
설치 예제에는, 방명록 응용프로그램에 대한 스마티 환경을 설정하게 될 것입니다. 디렉토리 명명을 정해두기 위해 응용프로그램을 택했을 뿐입니다. "guestbook"을 그냥 여러분의 응용프로그램 이름으로 바꾸어도, 아무 응용프로그램에 대해서 동일한 환경을 사용할 수 있습니다. 여기서는 스마티 디렉토리를 /web/www.example.com/smarty/guestbook/ 경로에 두겠습니다.
문서 루트에는 적어도 한 개의 파일이 있어야 하며, 그 파일은 웹 브라우저가 접근하는 스크립트입니다. 그 스크립트를 'index.php'라는 이름으로 만들고, /guestbook/ 이라는 문서 루트의 서브디렉토리 안에 넣도록 합니다.
기술 주석: 'index.php'가 디폴트 디렉토리 인덱스로 인식되도록 하기 위해 웹 서버를 설정하는 것은 편리하기 때문에, http://www.example.com/guestbook/ 에 접근시 'index.php'을 URL에 추가하지 않고도 'index.php' 스크립트가 실행될 것입니다. 아파치에서 여러분은 httpd.conf 예제에 있는대로 DirectoryIndex 세팅(각 엔트리가 빈 칸으로 구분된다)에 "index.php"를 추가함으로써 이것을 설정할 수 있습니다.
DirectoryIndex index.htm index.html index.php index.php3 default.html index.cgi
그럼 지금까지의 파일구조를 볼까요:
|
예제 2-6. 예제 파일 구조 |
|
예제 2-7. 파일 권한 설정 |
chown nobody:nobody /web/www.example.com/smarty/guestbook/ |
기술 주석: chmod 770 은 상당히 보안성이 엄격합니다. 유저 "nobody" 및 그룹 "nobody" 에게만 디렉토리로의 읽기/쓰기 접근을 허용합니다. 만일 누구든지 읽기 접근이 가능하도록 하려면(대체로 여러분 자신이 이 파일들을 보기 편하게 하려는 의도이죠), 775로 설정하면 됩니다.
스마티가 로드할 'index.tpl' 파일을 생성해야 합니다. 이 파일은 $template_dir에 넣을 겁니다.
이제 'index.php' 파일을 수정합니다. 스마티의 인스턴스를 생성하고나서, 템플릿 변수를 선언하고 'index.tpl' 파일을 보이도록 하겠습니다.
예제 2-9. /web/www.example.com/docs/guestbook/index.php 파일의 수정
<?php
// 스마티 라이브러리 로딩
require_once(SMARTY_DIR . 'Smarty.class.php');
$smarty = new Smarty();
$smarty->template_dir = '/web/www.example.com/smarty/
guestbook/templates/';
$smarty->compile_dir = '/web/www.example.com/smarty/
guestbook/templates_c/';
$smarty->config_dir = '/web/www.example.com/smarty/
guestbook/configs/';
$smarty->cache_dir = '/web/www.example.com/smarty/
guestbook/cache/';
$smarty->assign('name','Ned');
$smarty->display('index.tpl');
?>
기술 주석: 예제에서는, 모든 스마티 디렉토리에 대해 절대 경로를 설정합니다. 만약 /web/www.example.com/smarty/guestbook/ 디렉토리가 PHP include_path 안에 있다면, 이러한 세팅은 필요하지 않습니다. 하지만 (경험상) 절대 경로를 설정해 주는 것이 보다 효율적이며 적은 에러경향을 띱니다. 이것은 스마티가 여러분이 의도한 디렉토리의 파일을 읽어들이는 것을 확실하게 해줍니다.
자 이제 웹 브라우저에 index.php 파일을 띄워봅시다."Hello Ned, welcome to Smarty!"라는 문장이 보이실 겁니다.
이것으로 스마티 기본 설치는 마쳤습니다!
-------------------------------------------------------------------------
확장 설치(설정)
다음은 기본 설치 과정의 연장입니다. 이것을 읽기 전에 기본 설치를 반드시 읽어주세요!
스마티 설치의 약간 더 유연한 방법은 클래스를 확장시켜 여러분의 스마티 환경을 초기화하는 것입니다. 그리하여 반복적으로 디렉토리 경로를 설정해주는 대신, 한 곳에서 설정할 수 있는 동일한 변수 등을 선언해주는 것이지요. "/php/includes/guestbook/"라는 새 디렉토리를 생성하고 setup.php이라는 새 파일을 만들어봅시다. 예제 환경에서는, "/php/includes"는 include_path입니다. 이것도 설정하는 것을 확인하시거나, 아니면 절대 파일 경로를 사용하십시오.
|
예제 2-10. /php/includes/guestbook/setup.php 수정 |
<?php |
이제 setup.php를 사용하기 위해 index.php를 수정해봅시다:
|
예제 2-11. /web/www.example.com/docs/guestbook/index.php 수정 |
<?php |
이제 여러분은 그저 자동으로 응용프로그램에 대한 모든 것들을 초기화하는 Smarty_GuestBook 을 이용하여 스마티 인스턴스를 생성하는 것이 상당히 간단하다는 사실을 알았을 겁니다.
왜 스마티를 사용합니까?
출처: http://smarty.php.net/whyuse.php
번역: pinkhare(분홍토끼) in GTport
also available in Portuguese (포르투갈어 링크)
스마티의 우선적인 디자인 목표 중 하나는 표현양식(디자인)과 응용코드의 분리를 용이하게 하는 것입니다. 전형적으로, 응용 코드는 여러분 응용프로그램의 비지니스 로직을 포함하며, PHP 코드로 작성 및 유지됩니다. 이러한 코드는 프로그래머가 유지보수를 하죠. 프리젠테이션(디자인)은 최종 이용자에게 여러분의 내용물이 보여지는 방법이고, 템플릿 파일들로 작성되고 유지됩니다. 템플릿은 템플릿 디자이너가 유지보수를 하지요. 이렇듯 프로그래머와 템플릿 디자이너의 역할이 완벽히 분리됩니다.
Business Logic ; 비즈니스 로직
비즈니스 로직이란 업무에 필요한 데이터 처리를 수행하는 응용프로그램의 일부를 말한다. 이것은 데이터 입력, 수정, 조회 및 보고서 처리 등을 수행하는 루틴, 좀더 엄밀히 말하면 보이는 것의 그 뒤에서 일어나는 각종 처리를 의미한다. 대개 클라이언트 프로그램은 사용자 인터페이스와 비즈니스 로직으로 구성되며, 서버 프로그램은 대부분 비즈니스 로직만으로 되어 있다. 특히, 클라이언트/서버 모델인 경우에는 이외에도 통신링크가 추가되지만, 통신과 관련된 인프라스트럭처는 사용자 인터페이스처럼 비즈니스 로직의 일부는 아니다.
가장 기초적인 함수들에서, 응용프로그램 코드는 내용을 수집하고 템플릿 엔진에 그것을 선언하고, 표시합니다. 내용은 신문 기사의 헤드라인, 태크라인, 필자, 본문과 같은 것들이 되겠지요. 응용 코드는 이러한 내용이 템플릿에서 어떻게 표현될지 하는 점과는 관련이 없습니다. 템플릿 디자이너는 표현(디자인)영역에만 책임을 다하면 됩니다. 템플릿 디자이너는 템플릿 파일들을 편집하고, 마크업을 추가하고, 템플릿을 완성시킵니다. 이것은 보통 HTML 태그, 캐스케이딩 스타일시트, 템플릿 엔진에 제공되는 그밖의 도구들과 같은 것들을 포함합니다.
이러한 이론적 틀은 몇가지 의도를 충족시킵니다:
*) 디자이너는 응용프로그램 코드를 흐트리지 못합니다. 디자이너는 그들이 원하는 대로 템플릿을 마음껏 주무를 수 있지만, 코드는 여전히 그대로 남아있게 됩니다. 코드는 빈 틈 없이 치밀하고 보다 안전하며 유지보수가 쉽습니다.
*) 템플릿에서의 오류는 스마티의 에러 처리 루틴에 갇혀있고, 디자이너가 가능하면 그 오류들을 간단하고 직관적으로 이해할 수 있도록 해줍니다.
*) 자체 계층에서 템플릿을 디자인함으로써, 디자이너는 프로그래머와는 완벽히 별개로 스크래치(작업용 컴퓨터의 내부외부의 기억 매체)로부터 템플릿을 수정하거나 완전히 재설계를 할 수 있습니다.
*) 프로그래머는 템플릿에 관여하거나 다룰 수 없습니다. 프로그래머는 표현계층에는 손대지 않고 응용프로그램 코드의 유지, 내용이 얻어지는 방식의 변경, 새로운 처리규칙 생성 등만이 가능합니다.
*) 템플릿은 직관적 접근이며 최종 출력이 어떻게 보여지는지에 근접한 표현입니다. 디자이너는 내용이 어떻게 템플릿에 전달되는지는 상관하지 않습니다. 혹시 여러분이 템플릿에 SQL문과 같은 외부 데이터를 가지고 있다면, 이점은 실수로 삭제하거나 디자이너가 덮어씌우는 등으로 인한 위험 및 응용 코드의 파괴를 일으킬 수 있습니다.
*) 여러분은 임의적인 PHP 코드의 실행에 서버를 개방하지 않아도 됩니다. 스마티는 다수의 내장된 보안성 도구들을 가지고 있으므로, 디자이너가 고의든 실수든 보안성을 위반하는 일은 발생하지 않을 것입니다. 그 도구들은 템플릿 안에 들어있는 것만을 수행할 수 있습니다.
응용프로그램 코드가 표현요소와 분리되어 있다고는 하나, 그 의미가 굳이 로직이 분리되었다는 뜻은 아닙니다. 응용 코드는 분명히 로직을 포함하지만, 템플릿도 표현양식(디자인)만을 위한 것이라는 조건에서는 로직을 포함하는 것일 수 있습니다. 예를 들어, 디자이너가 테이블 열의 색상을 바꾸거나 내용에 일부 선언된 대문자를 치환하고자 한다면, 그것을 할 수가 있습니다. 이것이 프리젠테이션(디자인) 로직이며, 프로그래머와는 상관없는 것이죠. 한 줄에 표시되는 몇몇 표현요소들을 여러분은 얼마나 자주 두 줄 혹은 세 줄에 넣고 싶으셨었죠? 그리고 이것을 적용하기 위해 응용 코드는 얼마나 자주 수정하셨나요? 괜찮은 방법은 하나의 1차원 배열에 내용을 선언하고 템플릿이 표현요소를 처리하도록 하는 것입니다. 이렇게 하면 여러분의 응용프로그램을 간결화 해주고 템플릿을 유연하게 해줍니다. 스마티는 이러한 상황을 처리해주는 도구들을 지원합니다.
이 점은 스마티가 여러분이 템플릿에 응용 로직을 집어넣지 못하도록 되어있다는 의미는 아니고, 자제해야 한다는 거죠. 템플릿에 비지니스 로직을 연결한 예제를 보여드리죠. (맞아요, 가능하면 이렇게 하지 마세요):
{if $smarty.session.user and ( $user_type eq "editor" or |
위의 로직은 사용자가 로그인 되어있는지 그리고 편집자나 관리자인지를 검사하고 나서, 조건이 맞으면 편집이 허용되고 편집 체크박스가 보여집니다. 이것은 응용프로그램에 포함된 로직입니다. 템플릿은 이 사용자가 가진 자격권한이 어떤것인지는 상관하지 않고, 단지 편집 상자가 보여지느냐 안보여지느냐 하는 정보만 필요로 합니다. 따라서 보다 적절한 방법을 살펴봅시다:
{if $edit_flag}
<input type=checkbox name=edit value="y"> edit <br>
{/if}
|
템플릿에 간단하고 이해하기 쉬운 변수로 $edit_flag를 선언할 것인지는 응용 프로그래머에게 달려있습니다. 이 방법은 템플릿이 더이상 여러분의 기본 데이터 구조에 의존하지 않습니다. 세션 데이터 구조의 형식이 변경된다고 해도, 템플릿에서는 아무것도 조정(수정)할 필요가 없습니다.
스마티로 할 수 있는 몇 가지를 살펴봅시다. 하나는 맞춤 함수(사용자 함수)입니다. 이 함수들은 특정 작업을 실행하는 템플릿의 태그들입니다. 예제:
{html_image file="masthead.gif"}
|
여기서 "html_image"이라는 함수가 있지요. 이 함수는 "file" 애트리뷰트에서 주어진 이미지를 가져오며, 다음과 같은 HTML 코드와 맞먹는 모든 작업을 실행합니다:
<img src="masthead.gif" border="0" height="48" width="256"> |
이미지 함수는 높이(height)와 폭(width)을 계산한다든지 default(기본값) border 태그를 지원하는 등의 잡다한 일은 하지 않습니다. 물론 템플릿에 정적인 HTML 태그를 대신 사용할 수도 있겠지만, 여기서는 사용자 함수가 매우 일반적인 작업을 단순화하는데 어떻게 이용될 수 있는가 하는 점을 설명하고 있습니다. 디자이너는 기술적 작업은 되도록 줄이고 디자인에만 집중할 수 있습니다. 게다가 디자이너가 메인(로고) 이미지를 다른 크기로 삽입입하고자 한다면, 템플릿은 수정하지 않아도 됩니다.
html_image는 스마티에 내장된 함수입니다. 여러분 자신의 사용자 함수를 만드실 수도 있습니다. 다음 예제는 비슷해보이는 예제입니다:
{html_link type="article" id="abc123" text="Fire takes out Hotel"}
|
이것은 "html_link"라는 사용자 함수를 사용한 것입니다. 아래의 HTML 코드와 같은 의미이죠:
<a href="/display_article.php?id=abc123">Fire takes out Hotel</a> |
이것이 무엇을 하는 것입니까? 한 예로, 디자이너는 본문의 URL의 형식을 걱정할 필요가 없습니다. 하드코딩된 URL들에 있어서, 만약 프로그래머가 어느날 싹 정리를 하고서 URL 구문을 /display_article.php?id=abc123 에서 /ART/abc123 으로 변경하려고 한다면 어떨까요? 해당 본문의 URL이 들어있는 모든 템플릿 파일을 수정해야 할 것입니다. 이것은 템플릿 함수가 얼만큼 쉽게 템플릿을 유지보수할 수 있도록 해주는가를 보여주는 하나의 예일 뿐입니다.
그럼 이제 프로그래머와 템플릿에 대해 조금 얘기해보죠. 앞서 프로그래머가 템플릿이 내용에 어떤 것을 하던지에 관해서는 상관없다고 했습니다. 개념적인 단계에 있어서는 그게 사실입니다만, 현실 세계에서 여러분은 설마 템플릿 디자이너가 아무것도 없는 상태에서 그 모든 템플릿들을 전부 설계해야한다고 생각하지는 않을 것입니다. 결국, 비지니스 로직은 템플릿에 선언될 내용이 무엇인지를 결정합니다. 그래서 프로그래머는 보통 디자이너가 작업할 수 있도록 뼈대 템플릿을 설계합니다. 여기에는 보통 내용 변수와 섹션 루프 등의 가공되지 않은 요소들과 약간의 단순한 마크업 태그들이 포함되므로, 뒤죽박죽 되어있는 내용으로 시작하지는 않습니다. 다음 예제는 본문의 목록을 반복시키고 테이블에 그것들을 나타내주는 뼈대 템플릿입니다:
<table>
{section name=art loop=$article}
<tr>
<td>{$article[art].headline}<td>
<td>{$article[art].date}<td>
<td>{$article[art].author}<td>
</tr>
{/section}
</table> |
출력은 이렇게 될 것입니다:
<table> <tr> <td>How the west was won<td> <td>Dec 2, 1999<td> <td>John Wayne<td> </tr> <tr> <td>Team loses, Coach quits<td> <td>Feb 2, 2002<td> <td>John Smith<td> </tr> <tr> <td>Gourmet Cooking<td> <td>Jan 23, 1954<td> <td>Betty Crocker<td> </tr> </table> |
그럼 다음은 몇 가지 일반적인 질문을 보겠습니다:
결론적으로 왜 템플릿을 사용하죠? {$title} 대신에 <? echo $title; ?>를 쓰기가 무엇이 그리도 어려운 일인가요 (별로 어려운 일 같지 않은데요)?
판독하기 쉽게 하는 것이 디자인의 목적은 아니고, 주변 효과를 거둘려는 것이지요. 템플릿을 사용하면 위에 설명한 엄청난 잇점이 있습니다. 어쨌든 템플릿 환경에 있으므로, {$title} 가 <?php echo $title; ?> 보다는 비교적 덜 이질적이죠. 특히나 엄청 긴 내용이 작성된 페이지를 들여다볼 때 그렇다고 느끼실 겁니다. 그러므로 단순한 구문은 템플릿을 판독하고 유지보수 하는 일을 수월하게 해준다는 것은 꽤나 자명한 사실입니다.
템플릿은 구문 분석 시간이 걸리고, 응용프로그램을 훨씬 느리게 합니다.
어떤 점에선 그게 사실일 수 있지만, 스마티를 사용하는데 따른 구문 분석 속도는 PHP 스크립트를 실행하는 것보다 더 느리지는 않습니다. 템플릿을 처음 실행할 때, 스마티는 템플릿 파일들을 PHP 스크립트(템플릿 컴파일이라고 하죠)로 변환합니다. 그 후 PHP 스크립트가 그냥 포함될 뿐입니다. PHP 가속기와 스마티를 결합하면, 여러분은 진짜로 적은 오버헤드로 빠른 템플릿 처리 환경을 얻으실 수 있습니다.
스마티는 상당히 복잡한데, 과연 처리가 빠를 수 있을까요?
스마티의 핵심(내부)는 대체 뭘 할 수 있을까 싶을 정도로 상당히 간결합니다. 스마티의 대부분의 기능성은 플러그인에 달려있습니다. 플러그인 구조는 단지 필요한 플러그인들이 요구시 로드되도록 하기 위해 설계되었습니다. 이러한 프레임워크를 가지고, 수백 개의 새로운 플러그인을 추가하더라도 성능에 영향을 미치지 않습니다. 이 때문에 스마티는 빠르고, 확장성있고, 유연한 것입니다.
또한 스마티는 캐싱 도구도 가지고 있는데, 그 도구는 여러분의 마음에 드는 저장되지 않은 페이지의 부분들을 동적으로 새로고침하고 유지합니다. 캐싱은 컴파일된 템플릿의 출력물을 저장하여, 요청시마다 실행할 필요를 덜어주게 됩니다.
이 모든 것이 가속기에 대한 논의인데, 가속기 하나 없이 스마티는 어떻게 작동됩니까?
실제로 스마티는 가속기 하나 없이 잘 작동합니다. 스마티는 가속기가 필요없지만, 템플릿 파일 자체는 가속기가 있다면 이로울 겁니다. 그건 스마티에 있어서 독보적인 점이기도 하죠 (AFAIK: 제가 알고 있는 한). 여러분이 가속기가 없다면, 템플릿 실행은 그렇게 빠르지는 않아도 구문 분석을 하지 않기 때문에 그다지 느리지도 않습니다. 게다가 스마티의 모든 나머지 장점과 특징들이 있죠. 뿐만 아니라, 가속기가 무료로 사용 가능하므로 실제로 가속기 하나도 사용하지 않는다는 변명은 있을 수 없습니다. 가속기는 스마티를 사용하든 안하든 PHP 응용프로그램에서 그 성능을 발휘할 것입니다.
유지보수가 대체 얼만큼이나 수월해진다는 겁니까?
몇 가지는 설명되지 않는 것도 있네요, 실제로 경험에 의해서만 느낄 수 있다고나 할까요 :-) 응용프로그램의 로직과 표현요소(디자인)을 분리시키는 것의 장점은 그다지 부각될 수 없습니다. 스마티는 쾌적한 오류 처리 도구 및 내장 디버깅 콘솔이 있어서, 여러분은 템플릿의 계층구조 및 선언 변수들을 한 눈에 알아볼 수 있습니다. 스마티에 사용자 도구들을 추가하는 것은 플러그인 디렉토리에 그것을 넣은 뒤 템플릿에 그것을 정의해주기만 하면 될 정도로 간단합니다.
템플릿 태그가 XML 기반이 아닌데요, 제가 사용하는 편집기에 맞지 않는 것 같네요.
{} 구획문자(delimiter)는 기본값(디폴트)입니다. HTML 태그들 사이에서 쉽게 분간할 수 있습니다. 그 표현이 싫으시다면, 구획문자를 <% %>로 바꾸시든지, 좀 더 XML틱 하게 <smarty: >로 바꾸시면 되겠네요. 드림위버나 그런 비슷한 툴에 있어서 많은 배포자가 있으니, 배포 공간에 한 번 질문해 보시지요.
스마티에 대해 요약하자면, 여러분은 웹 응용프로그램 설계를 위한 툴의 축적에 스마티를 추가하실 수 있습니다. 제대로 좀 더 공부하시려면, 상단부터 하단까지 있는 버튼들의 매뉴얼을 읽어보세요, 포럼에도 가입하시고 사람들이 토론중인 내용에 대해서도 한 번 보세요.
02
스마티가 뭐에요?
급변하는 웹 세상이라지만 갑자기 개벽이라도 일어난 것일까요?
이미 예정된 것이었을지도 모르는 일이지만, 압도적인 제로보드의 새로운 작품인 zb5 가
베타로 그 모습을 드러내자마자 이러한 움직임은 한 층 급속하게 번지는 듯 보입니다.
스마티? 대체.. !
그럼 영어사전에서 일단 원래의 사전적 뜻을 찾아보죠.
smarty [sm
ti] 
미구어
n. (pl. smarties) = SMART ALECK
a. (smartier; -iest) = SMART-ALECKY출처: empas(엠파스) 영한사전
smart
al
ecky [-
liki]a. 잘난 체하는, 똑똑한 체하는, 자만심이 강한오오.. 잘난척 하는 언어인가보죠 ? ㅎ_ㅎ;
사실 그만큼 처리 면에서 영리하고 유용하다는 뜻에서 붙여진 이름으로 보입니다.
스마티 공식 사이트의 도안은 '빛이 번쩍이는 전구' 그림인데요. 정말 튀는 느낌이 드네요.
그럼 이제 스마티 공식 사이트로 잠깐 가서 어떻게 생긴 곳인지 슬그머니 둘러볼까요?
http://smarty.php.net/rightforme.php
오오~ , 사이트 주소를 보니 php.net 의 2차 도메인이로군요! 그렇다면 뭔가 PHP와도 관련이 있다는걸 눈치채셨나요?
스마티 공식 사이트에 정의된 것을 그대로 가져왔습니다. (번역: pinkhare(분홍토끼) in GTport)
-----------------------------------------------------------------------------------------------------
스마티가 저에게 적당할까요?
스마티가 "템플릿 엔진"으로 알려져있기는 하지만, "템플릿/프리젠테이션 프레임워크"라는 표현이 더 정확하겠지요. 즉, 스마티는 많은 툴을 이용하여 프로그래머와 템플릿 디자이너가 어플리케이션의 프리젠테이션(표현) 계층에서 공통적으로 처리되는 작업들을 자동화시킬 수 있게 해줍니다. 스마티는 단순한 태그를 대체하는 템플릿 엔진이 아니므로, 저는 프레임워크라는 단어를 강조합니다. 물론 단순한 용도로 사용될 수도 있기는 하지만, 핵심은 고성능, 확장성, 보안성, 추후의 성장성 등을 유지하면서도 여러분의 어플리케이션을 빠르고 쉽게 개발하고 전개할 수 있도록 하는게 목적이죠.
스마티의 두드러진 특징 몇 가지를 정리해보죠 :
캐싱: 스마티는 표현된 웹페이지의 전체 혹은 일부의 잘 다듬어진 캐싱(저장) 혹은 저장(캐시)되지 않은 부분의 방치를 위한 성질을 제공합니다. 프로그래머는 cacheable이나 non-cachable과 같은 템플릿 함수들을 등록할 수 있으며, 보다 편리한 관리 등을 위해 논리 단위들로 저장된 페이지들을 묶습니다.
설정 파일: 스마티는 설정 파일에서 제외된 변수들을 정의할 수 있습니다. 템플릿 디자이너는 프로그래머에게 간섭받지 않고 하나의 장소에 몇 가지 템플릿들에 공통된 값들을 유지할 수 있으며, 어플리케이션의 프로그래밍 부분과 프리젠테이션(표현/디자인) 부분간에 구성 변수들이 손쉽게 공유될 수 있습니다.
보안성: 템플릿은 PHP 코드를 담고 있지 않습니다. 따라서 프로그래머가 그러한 전체 기능들을 가능하게 만들어놓은 기능성의 부분집합을 제외하고는, 템플릿 디자이너가 PHP의 전체 기능을 자유롭게 이용하지 못합니다.
사용 및 유지보수의 편리성: 웹페이지 디자이너는 PHP 코드 문법을 처리하지는 않고, 간단한 HTML보다도 어렵지 않고 이용이 간편한 템플릿 문법을 다룹니다. 템플릿은 최종 출력물에 거의 근접한 표현이며 디자인 공정을 놀랍게 줄여줍니다.
다양한 변경자: 모든 대문자, html-이스케이프 문자, 포맷일자, 텍스트 구간 자르기, 문자간 공백 삽입 등에 있어서 표시하는 것과 같은 그러한 선언 변수의 내용들이 변경자로 display-time에 간편히 조절될 수 있습니다. 다시 말하면, 이러한 것은 프로그래머로부터 간섭받지 않고 이루어집니다.
템플릿 함수: 템플릿 디자이너는 HTML 코드 조각들(드롭다운, 테이블, 팝업 등)을 생성하는 것, 그때그때 즉시 처리하는 다른 템플릿들의 내용을 표시하는 것, 내용의 배열 루프시키기, 이메일 출력을 위해 텍스트를 형식화 하기, 색상 순환 등의 작업 처리에 많은 함수들을 사용할 수 있습니다.
필터: 프로그래머는 전처리 필터(pre-filters), 후처리 필터(post-filters), 출력필터를 이용하여 템플릿 출력물 및 컴파일된 템플릿 내용을 전체적으로 제어할 수 있습니다.
자원: 새로운 자원 처리기를 생성하고 템플릿에서 그것을 사용함으로써 템플릿은 얼마나 많은 소스에서든지 제외될 수 있습니다.
플러그인: 스마티의 거의 모든 관점들은 플러그인을 사용함으로써 제어됩니다. 일반적으로 플러그인 디렉토리에 플러그인을 끌어다 놓고 템플릿에서 그것들을 적어주거나 어플리케이션 코드에서 그것들을 사용하면 될 정도로 쉽습니다. 다수의 사용자 커뮤니티의 기증도 가능합니다. (포럼 및 위키의 플러그인 부분 참조)
애드온: 많은 사용자 커뮤니티 기증 애드온(부속품)들은 페이지매김, 양식 인증, 드롭다운 메뉴, 달력 날짜 선택기(picker) 등과 같은 것이 가능합니다. 이러한 도구들은 개발 주기를 단축시켜주고, 전개하기 위한 안정 및 준비가 미리 되어있기 때문에 코드의 순환 및 디버그를 재 고안하지 않아도 됩니다. (포럼 및 위키의 애드온 부분 참조)
디버깅: 스마티는 내장된 디버깅 콘솔(제어기)을 갖추고 있으므로, 템플릿 디자이너는 선언된 변수 전체를 볼 수 있고, 프로그래머는 템플릿 렌더링(번역) 속도를 검사할 수 있습니다.
컴파일링: 스마티는 템플릿의 실시간 구문분석(파싱)을 제거하면서 템플릿을 보이지 않게 PHP 코드로 컴파일합니다.
성능: 스마티는 어마어마한 도구 집합이 있음에도 불구하고 매우 쾌적하게 실행합니다. 스마티 능력은 필요에 따라 로드되는 플러그인에 달려있습니다. 스마티는 엄청난 양의 프리젠테이션 도구들에 부속하며, 여러분의 응용프로그램 코드를 최소화 해주고 빠르고 더 적은 에러경향의 어플리케이션 개발 및 전개 결과를 제공해 줄 것입니다. 스마티 템플릿은 손실이 큰 템플릿 파일 스캔을 삭제하고 op-code 가속기의 속도를 기하급수적으로 끌어올리면서 내부적으로 (1회) PHP 파일로 컴파일됩니다.
자 그럼 이제는, 여러분께 스마티가 적합한가요? 문제는 작업에 대해 적절한 툴을 사용하는 데 달려있습니다. 혹시 여러분이 간단한 변수 치환을 하고 싶다면, 좀 더 단순한 툴을 찾거나 혹은 직접 일일이 하려고 하실겁니다. 만일 여러분의 어플리케이션이 향후 진화함에 따라 여러분의 작업을 편리하게 해 줄 다수의 툴과 더불어 견고한 템플릿 프레임워크를 원하신다면, 스마티는 훌륭한 선택이 될 것입니다.
-----------------------------------------------------------------------------------------------------
Cf) Smarty에서 빈번히 등장하는 용어 template(템플릿) 이란?
template [tmplt] n.
1 본뜨는 공구(工具), 형판(型板)
2 건축 보받이, 도리받이
3 조선대(造船臺)의 쐐기; (반)투명의 피복지(彼覆紙)
4 생화학 (핵산의) 주형(鑄型)
5 컴퓨터 보기판, 템플릿 ((키보드 위에 놓고 각 키에 할당된 명령의 내용을 보이는 시트))
--> 아하! 그렇다면 우리말로 거푸집 (혹은 붕어빵 제조기) 같은거겠네요.
기본적으로 제공되는 하나의 틀로써, 사용자가 마음대로 변형하고 추가하면서 새로 변형된 복제물을
손쉽게 생성해서 이용할 수 있는 그런 개념인 것 같네요.