PHP 대 템플릿 엔진
저는 현재 PHP를 템플릿 엔진으로 사용하는 것과 PHP를 기반으로하는 템플릿 엔진 중에서 선택하는 것에 대해 논의하고 있습니다.
당신의 선택은 무엇이며 그 이유는 무엇입니까?
PHP가 템플릿 엔진 자체 일 때 다른 템플릿 엔진을 사용하는 이유를 설명합니다.
템플릿 엔진의 경우 :
- 최종 사용자 사용자 지정을위한 보안이 추가되었습니다. 순수 PHP의 테마는 사용자와 설치에 해를 끼칠 수있는 제한없는 기능을 가지고 있습니다. 따라서 템플릿 엔진이 좋은 경우 해당 위험을 제거합니다.
- 그래픽 아티스트 나 웹 디자이너와 같이 프로그래머가 아닌 사람도 쉽게 사용할 수 있습니다.
일반 PHP의 경우 :
- 순수한 PHP의 속도는 그 위에 구축 된 템플릿 엔진과 비교할 수 없습니다.
- 해석되거나 필터링 된 부분뿐만 아니라 PHP 의 모든 기능을 출력에 사용할 수 있습니다.
가능하다면 PHP 자체를 선호합니다. 그리고 대부분의 사람들은 사용자 지정 테마를 만들어 소프트웨어를 해킹하는 것을 원하지 않으므로 간단하게 읽고 보안을 조사하는 것이 쉽습니다. 즉, 나는 템플릿과 프로그래밍, 심지어는 그래픽 아트를하는 "중간자"입니다. 내 스킬 셋은 엄격한 프로그래머 및 엄격한 아티스트 / 디자이너와 다릅니다.
Smarty를 소개했을 때 웹 디자이너가 똑똑한 변수를 사용하여 HTML을 생성하도록하는 것이 매우 간단하다는 것을 알았습니다. 프로그래밍 팀의 사람들은 이제 더 많은 백엔드 작업, 즉 Smarty 변수의 콘텐츠 제작에 집중합니다.
이로 인해 개발 수명주기가 단축되고 작업이 더 많은 사람에게 분할 될 수 있으며 궁극적으로 더 나은 설계로 이어졌습니다.
글쎄, 내 의견 일 뿐이지 만 템플릿 엔진은 형편 없다. 먼저 템플릿 엔진이 구현되는 방식을 이해 한 다음이를 사용하는 방법을 배워야합니다. PHP만으로도 최선을 다하고 훨씬 더 많은 유연성을 제공하기 때문에 시간 낭비 인 것 같습니다.
다음과 같은 이유가 적용됩니다.
- 엔진을 사용하여 애플리케이션을 템플릿으로 분리하면 애플리케이션이 코드 오류 중지에 덜 취약 해집니다.
- 템플릿을 사용하면 네임 스페이스가 애플리케이션에 직접 빌드되지 않으므로 향후 리팩토링 할 때 더 큰 유연성을 얻을 수 있습니다.
- 템플릿을 사용하면 개발자가 비즈니스 로직과 코드를 프레젠테이션 레이어에서 벗어나게 할 수 있습니다.
- 템플릿을 사용하면 데이터 세트를 더 쉽게 모의하여 템플릿 엔진에 전달하고 데이터로 사이트가 어떻게 표시되는지 미리 볼 수 있습니다.
템플릿을 수행하는 프로그래머가 아닌 경우 템플릿 엔진을 사용하면 도움이 될 수 있습니다. 대부분의 경우 단순화 된 템플릿 언어는 프로그래머가 아닌 사람이 PHP 자체보다 쉽게 선택할 수 있습니다.
즉, 저 (또는 저와 다른 개발자) 만 템플릿을 사용하지 않습니다.
PHP 는 템플릿 엔진이 아니라 템플릿이나 템플릿 엔진을 작성하는 데 사용할 수있는 언어입니다. 템플릿 엔진은 단순한 언어가 아니라 스크립트가 템플릿을 찾거나 구성하거나 스크립트의 데이터를 할당 할 수 있도록하는 프로그래밍 API이기도합니다. 순수 PHP는 당신에게 아무것도 제공하지 않습니다. 단지 언어 일뿐입니다. 대신 Zend Framework의 Zend_View와 같은 라이브러리를 사용하여 비교해야합니다 (기본적으로 템플릿을 작성하는 데 PHP를 사용한다는 점을 제외하면 Smarty와 동일한 방식으로 작동합니다). PHP와 함께 템플릿 엔진을 사용할 것인지 아니면 다른 것을 템플릿 언어로 사용할 것인지 물어봐야합니다.
언어 자체를 템플릿화할 때는 일반적으로 루프와 조건만으로도 템플릿을 작성할 수 있습니다.하지만 이것이 "충분하다"는 것이 쉽고 편안하고 효율적이거나 유연하다는 의미는 아닙니다. PHP는 템플릿 디자이너에게 특별한 것을 제공하지 않지만 많은 "템플릿 언어"(예 : Smarty)는 PHP의 제한된 하위 집합 만 제공하므로 프로그래머가 PHP를 선택하는 것이 놀랍지 않습니다. 적어도 그들은 함수를 작성하고 (제 의견으로는) 너무 방대한 OOP를 사용할 수 있지만 작동하고 실제로 도움이됩니다.
요점은 사용자 정의 템플릿 언어는 PHP의 단점으로 제한되지 않지만 설계자들은 "변수와 루프를 표시하는 것으로 충분하다"고 주장하면서 의심 할 여지없이이를 인식하지 못한다는 것입니다. 템플릿 언어가 훨씬 더 효과적 일 수있는 가능한 영역 :
- 양식 표시 및 렌더링 (폼 모양을 사용자 정의하기위한 쉽고 유연하며 일반적인 시스템을 제공하는 템플릿 언어로 PHP를 사용하는 프레임 워크를 본 적이 없습니다).
- HTML / XML 문서 구조 이해.
- 자동 XSS 주입 필터.
- 프레젠테이션 레이어의 다양한 일반적인 문제 해결 (예 : 페이지 매김 시스템의 모양 사용자 지정, 열에 데이터 표시 등)
- 템플릿 이식성 및 템플릿 에서 애플리케이션 로직 및 구현 세부 사항의 진정한 분리.
이러한 방식을 따르는 템플릿 언어의 예는 PHPTAL 및 Open Power Template 2 위에 언급되어 있습니다. TinyButStrong에서도 유사한 아이디어를 찾을 수 있지만 안타깝게도이 템플릿 엔진은 매우 느립니다.
템플릿 엔진으로서의 PHP는 HTML 구문을 혼동 할 때 불평하지 않습니다. 태그를 닫거나 잘못 중첩하는 것을 잊을 수 있습니다.
PHP의 출력은 기본적으로 이스케이프되지 않으므로 htmlspecialchars()
모든 곳에 엄격하게 추가하는 것을 기억하지 않는 한 사이트에 HTML 주입 (XSS) 취약성이 있습니다.
<p>Hello <?= $name ?></b>
<!-- Simple template full of errors -->
이러한 문제는 XHTML을 올바르게 생성하려고 할 때 훨씬 더 심각합니다 . 평범한 PHP로는 할 수 없다는 것이 아닙니다. 물론 할 수 있습니다.하지만 더 많은 노력과 부지런함이 필요합니다.
그래서 내 추천은 PHPTAL 입니다. OPT2 도 괜찮습니다.
Savant는 당신이 찾고있는 것입니다. PHP 위에 새로운 템플릿 언어를 해석하는 대신 템플릿에서 PHP 연산자를 사용할 수있는 멋진 래퍼 클래스입니다.
장점 :
시스템에 추가 작업을 추가하지 않는 것이 좋습니다.
개발자를위한 학습 곡선 없음 모두가 훈련을 받았다면 이것이 갈 길입니다. (학자)
단점 :
Savant가 적절하게 분리하도록 권장하지만 개발자가 개발 코드에서 비즈니스 로직을 분리하도록 강요하지는 않습니다. 나는 절대로 어길 수없는 규칙이 있습니다. 템플릿에서 변수를 출력하고 조건 및 루프를 사용할 수만 있습니다. 개발자가 템플릿에서 변수를 생성하도록 허용해서는 안됩니다. 안타깝게도 개발자는 아무리 많이 말해도 이렇게하지 않는 것 같습니다. 따라서 Smarty와 같은 엔진을 사용하면 개발자가 비즈니스와 디자인을 완전히 분리해야하기 때문에 그만한 가치가 있습니다.
나 자신을 위해 또는 개발자가 많지 않은 프로젝트를 수행하는 경우 Savant를 사용하는 경향이 있습니다. 나보다 훨씬 큰 프로젝트라면 Architecture에서 Smarty와 같은 것을 할 것입니다.
어느 쪽이든 코드의 분리는 Savant 또는 Smarty를 사용하는 중요한 날씨입니다. 나는 거기에 다른 좋은 옵션도 있다고 확신합니다.
PHP는 대부분의 작업에 완벽하게 적합하지만 템플릿 엔진을 사용하면 프로젝트를보다 쉽게 확장 할 수 있습니다.
Smarty 또는 PHPTAL 과 같은 기성품 은 스스로 롤링 할 시간이없는 경우에 좋습니다 (그리고 제공하는 것보다 더 많이 필요하지 않음). 또한 좀 더 전문화 된 것이 필요하다면 나중에 자신의 구현으로 쉽게 교체 / 수정할 수 있습니다.
I've personally had a good experience with PHPTAL, primarily because it keeps out of your way and is simple.
I found building a light-weight template engine in PHP worked best for us. Allows for good code separation, and our graphic designer could learn a few simple rules to follow, but most writes HTML/CSS not PHP. I can write the heavy lifting code without having the think much about the interface.
The following article sum-up the different points of view about Template Engines for PHP.
Doing PHP templates of the third kind http://www.tinybutstrong.com/article_3rd_kind.html
My choice for any new project would probably be to simply use the templating capabilities of PHP, possibly in combination with an MVC framework, instead of using another templating engine. After all, for code simplicity or cleanliness of separation, it doesn't really matter whether you have {$myVar}
or <?= $myVar ?>
in your code. More complex templating features such as conditions, loops, or backend-technologies such as caching can be handled just as well (or better) by PHP or the MVC framework.
I have used both approaches (with and without a templating engine), but only in personal projects, never in team projects, so perhaps there are compelling arguments for the use of a templating engine in such a setting.
I don't know whether it is due VirtueMart, Joomla or the concept of templates in PHP, but adjusting VirtueMart to your own graphic theme is PURE HELL. (I'm not talking about plain CSS-styling.)
PHP isn't a templating engine its a scripting language.
PHP coding features evolved, designing feature are the same, that's why if you work in a team with designers and developer you need a template engine to parallelize the job, and let the designers work with HTML.
My personal choice is Raintpl, because is lightweight, friendly and fast here a benchmark can help you choose (also smarty and savant are nice!):
http://www.raintpl.com/PHP-Template-Engines-Speed-Test/
If I had to spend the time learning a standalone template engine, I would rather spend the time learning a Framework instead. My choice is to go with Zend Framework, which when implemented using an MVC approach, provides you with the power of the framework, along with the native templating capability of PHP itself.
Since I asked this question, I have came across mustache. This is a logic-less template language.
So this is not the same as PHP or smarty where you have the possibility to add all sorts of logic to you template, but forces you to keep all the logic in something like view models.
This seems to me a better option then switching to template language where logic is still possible.
I use a template engine in PHP because I prefer to have a high degree of separation between business logic and presentation logic. Web programming is much easier when your PHP (or any other programming language) doesn't have HTML scattered throughout. This is Microsoft's code behind is so popular.
I use a template engine called KudzuPHP. It is a port of my KudzuASP for Classic ASP. It differs from many template engines in that the code that hosts the business rules and logic becomes an event handler for the template engine after the template engine is invoked. This approach allows you to modify the templates (moving large blocks of presentation) without requiring you to modify the code of the PHP code.
KudzuPHP contains it's own library system and writing new extension tags and libraries is very easy.
You can find KudzuPHP here: http://www.andrewfriedl.com/downloads/ If you want a version embedded in a Wordpress plugin that allows you to code against the Wordpress API without PHP go top Wordpress.org and search the plugins for "Kazoo".
currently, it the most faster and easier to use. After making a suite of benchmark on PHP templates engines, twig comes in the second place just after native php language.
I wrote a blog post about this recently.
For the security sake alone, definitely use a templating engine ( Twig is secure ).
A good templating engine (such as Twig) offers:
- Security (most important what so ever )
- Not verbose (like php)
- More templating features
참고URL : https://stackoverflow.com/questions/731743/php-vs-template-engine
'IT TIP' 카테고리의 다른 글
Mac 또는 Mac OS X에서 localhost 폴더는 어디에 있습니까? (0) | 2020.12.02 |
---|---|
CURRENT_TIMESTAMP (밀리 초) (0) | 2020.12.02 |
Internet Explorer는 일부 도메인의 쿠키를 무시합니다 (쿠키를 읽거나 설정할 수 없음) (0) | 2020.12.02 |
하위 문자열 발생을 계산하는 방법은 무엇입니까? (0) | 2020.12.02 |
PHP 날짜 (); (0) | 2020.12.02 |