문제

PHP에서 템플릿 시스템을 사용해야 하는 이유는 무엇입니까?

내 질문의 이유는 다음과 같습니다.PHP 자체는 기능이 풍부한 템플릿 시스템인데 왜 다른 템플릿 엔진을 설치해야 합니까?

지금까지 내가 찾은 유일한 두 가지 장점은 다음과 같습니다.

  1. 좀 더 깔끔한 구문(때때로)
  2. 템플릿 엔진은 일반적으로 비즈니스 로직을 구현할 만큼 강력하지 않으므로 문제를 분리해야 합니다.PHP를 사용한 템플릿은 템플릿 원칙을 살펴보고 코드 수프 작성을 다시 시작하도록 유도할 수 있습니다.

...단점과 비교할 때 둘 다 매우 무시할 수 있습니다.

작은 예:

PHP

<h1><?=$title?></h1>
<ul>
  <? foreach ($items as $item) {?>
  <li><?=$item?></li>
  <? } ?>
</ul>

똑똑하다

<h1>{$title}</h1>
<ul>
  {foreach item=item from=$items}
  <li>{$item}</li>
  {/foreach}
</ul>

실제로는 전혀 차이가 없습니다.

도움이 되었습니까?

해결책

예, 말했듯이, PHP (템플릿 엔진) 내부에서 템플릿 엔진을 사용하도록 강요하지 않으면 미끄러 져 갈기가 쉽게 분리되지 않습니다.

하지만, 우려 사항을 분리하는 데 문제가있는 동일한 사람들은 HTML을 생성하고 Smarty에 공급하거나 Smarty에서 PHP 코드를 실행하여 Smarty는 우려 분리 문제를 거의 해결하지 못합니다.

또한보십시오:

다른 팁

사람들이 템플릿 시스템을 사용하는 주된 이유는 논리를 프레젠테이션과 분리하는 것입니다. 그로부터 오는 몇 가지 이점이 있습니다.

첫째, 코드의 흐름을 유지하는 것에 대해 걱정할 필요없이 템플릿을 착용 할 때 적합한 것을 움직일 수있는 웹 디자이너에게 템플릿을 나눠 줄 수 있습니다. 그들은 특별한 태그를 내버려두기 위해 PHP를 이해할 필요가 없습니다. 그들은 몇 가지 태그에 대해 몇 가지 간단한 의미를 배워야 할 수도 있지만 전체 언어를 배우는 것보다 훨씬 간단합니다.

또한 페이지를 별도의 파일로 나누면 프로그래머와 디자이너 모두 동일한 '페이지'에서 한 번에 동일한 '페이지'에서 작동하여 충돌없이 필요한대로 소스 제어를 체크인 할 수 있습니다. 디자이너는 안정적인 버전의 코드에 대해 템플릿 비주얼을 테스트 할 수 있으며 프로그래머는 자신의 사본에 대해 잠재적으로 잠재적으로 변화를 일으킬 수 있습니다. 그러나이 사람들이 동일한 파일을 편집하고 다른 변경으로 병합해야한다면 문제가 발생할 수 있습니다.

또한 비즈니스 논리를 프레젠테이션 로직에서 멀리 유지하는 데 좋은 프로그래밍 실무를 시행합니다. 프레젠테이션과 비즈니스 로직을 혼합 한 경우 나중에 다르게 제시 해야하는 경우 추출하는 데 더 어려운 시간이 있습니다. RSS/ATOM 피드, JSON 또는 AJAX 응답, 핸드 헬드 장치 용 WML 등 웹 앱의 다양한 프레젠테이션 모드가 점점 인기가 높아지고 있습니다. 템플릿 시스템을 사용하면 종종 템플릿으로 전적으로 수행 할 수 있으며 아무것도 변경하지 않아도됩니다. 또 다른.

그러나 모든 사람이 이러한 혜택을 필요로하거나 이해하는 것은 아닙니다. Java/Python/Ruby/등에 대한 PHP의 장점은 웹 페이지를 일부 논리로 신속하게 해킹 할 수 있다는 것입니다.

논리를 분리하는 변명으로 비 PHP 템플릿을 사용하는 것은 말도 안됩니다. 개발자가 비즈니스 뷰로 논리 분리가 무엇인지, 어떻게 수행 해야하는지 이해하지 못하면 문제를 적절하게 해결해야합니다. 그렇지 않으면 템플릿의 비즈니스 로직 또는 비즈니스 로직에서 HTML로 끝납니다. 템플릿 엔진이 절약되지 않습니다. 개발자에게 기본 사항을 가르쳐야합니다.

그리고 개발자라면 하다 템플릿 시스템은 제한 일뿐입니다. 추가하지 않습니다 모든 가치 개발 프로세스에는 새로운 구문을 배우고 다른 라이브러리를 최신 상태로 유지하고 실행 속도가 느려집니다. 후자는 캐싱과 그 밖의 것과 함께 해결 될 수 있지만, 이것은 존재하지 않는 문제를 해결합니다. 따라서 템플릿 시스템은 가치가없고 전혀 이점이 없습니다.

그러나 비 PHP 템플릿 시스템을 사용하는 것이 합리적이라고 생각하는 한 가지 예외가 있습니다. 뷰-로그 프로그래머가 템플릿에 대한 액세스가 제한되어 있어야합니다. 예를 들어 블로그 호스팅 시스템의 제공자이고 사용자가 임의의 코드를 실행할 수 있도록 템플릿을 개인화하고 코딩 할 수 있도록 허용하는 경우. 그러나이 주장은 그렇습니다 ~ 아니다 디자이너가 UI를 프로그래밍하는 데 도움이되는 작은 코드를 기꺼이 배우는 경우에 적용하십시오. 그가 Smarty를 배울 수 있다면 그는 할 수 있습니다 확실히 PHP를 배우십시오.

여전히 템플릿 시스템을 사용해야할만한 이유가 있지만 똑똑하지는 않지만 phptal. PHPTAL 템플릿은 유효한 XML (따라서 XHTML) 파일입니다. phptal에서 더미 컨텐츠를 더 많이 사용할 수 있으므로 최종 모양으로 유효한 XHTML 파일을 얻을 수 있습니다. 이는 표준 도구로 처리하고 테스트 할 수 있습니다. 다음은 작은 예입니다.

<table>
  <thead>
    <tr>
      <th>First Name</th>
      <th>Last Name</th>
      <th>Age</th>
    </tr>
  </thead>
  <tbody>
    <tr tal:repeat="users user">
      <td tal:content="user/first_name">Max</td>
      <td tal:content="user/last_name">Mustermann</td>
      <td tal:content="user/age">29</td>
    </tr>
  </tbody>
</table>

PHPTAL 템플릿 엔진은 사용자 어레이에서 모든 값을 자동으로 삽입하고 더미 값을 교체합니다. 그럼에도 불구하고, 테이블은 이미 선택한 브라우저에 표시 될 수있는 유효한 XHTML입니다.

저에게있어 템플릿 엔진의 큰 기능 중 하나는 캐시 계층이 투명하다는 것입니다. 나는 오래 전에 Smarty를 사용해 왔으며 캐시 물건은 삶을 더 쉽게 만듭니다. 또한 Smarty Design을 사용하면 자신의 캐시 기능을 사용할 수 있습니다. 내 경우에는 일부 페이지에서 Memcache 또는 Disk를 사용하여 템플릿 출력을 저장 해야하는지 선택합니다.

반면에 사이트에 트래픽이 크고 Smarty를 관리하고 잘 조정하는 방법을 모르면이 템플릿 엔진이 사이트 킬러가 될 수 있습니다. 그러나 Smarty를 사용하지 않더라도 사이트도 죽을 수도 있습니다.

Flickr는 현재 Smarty를 사용하고 있습니다. 너무 나쁘지 않아야합니다.

PHP ~이다 거의 템플릿 시스템입니다.핵심은 스스로 논리와 프레젠테이션을 분리하도록 강요하는 것입니다.Smarty 등을 사용하면 로직과 프리젠테이션을 혼합하는 것이 약간 더 불편해질 뿐입니다.스스로 분리할 수 없다면 템플릿 시스템을 사용해도 도움이 되지 않습니다.앞으로 할 일은 추가 처리 능력을 소모하는 것뿐입니다.

핵심은 프레젠테이션 코드의 값을 변경하지 않는 것입니다.이를 위해 if/endif 구문을 사용하면 PHP 자체가 Smarty만큼 효과적이라고 생각합니다.

<?php if($some_test): ?>
   <em>Some text!</em>
<?php endif; ?>

대부분 나는 템플릿에 적용될 "안전하지 않은"백엔드 로직을 피하는 것으로 생각합니다. 대부분의 시간 템플릿은 디자이너에게 전달되므로, 우리는 그들에게 그들이 할 수있는 일을 닫는 것만 제공하고 싶습니다.

나는 모든 PHP 파일에서 템플릿을 사소하게 표시 할 수있는 기능을 좋아합니다 (Nav Bars와 같은 일반적인 요소에 대해 서로 내부에 템플릿 조각을 포함). 예를 들어, 로그인 한 경우 일반적으로 정보를 인쇄하는 페이지 나 오류가 아닌 경우 오류가 있다고 가정합니다. PHP를 사용하면 다음과 같은 글을 쓸 것입니다.

if (loggedIn)
{
    // print lots of HTML here
}
else
{
    // print error message
}

Smarty에서는 이와 같은 것일 수 있습니다 (아마도 내 잘못된 구문을 용서하십시오. 오랜만에) :

if (loggedIn)
{
    $smarty->bind("info", someObject);
    $smarty->display("info.template");
}
else
    $smarty->display("error.template");

정말 영리한 경우, 사용자가 왜 그곳에 있는지 설명하는 메시지와 함께 오류 템플릿 대신 로그인 페이지 템플릿을 표시 할 수도 있습니다. 그리고 내가 쓴 대로이 기술을 사용하여 로그인 상자를 표시하기로 결정했다면 단일 라인 변경 일뿐입니다! 저에게는 시야와 논리의 분리를 유지하는 것이 아니라 많은 곳에서 시야의 공통 요소를 재사용하는 능력에 관한 것입니다.

Code Igniter와 같은 MVC 프레임 워크를 사용하는 것이 기쁩니다. '보기'에서 값이 표시되는 방식과 관련된 PHP 코드를 고수하는 경향이 있음을 알게됩니다. 그 효과에 대한 견해에서 사용할 수있는 서식 함수 라이브러리가 있습니다. 코드 점화기의 구내 중 하나는 귀하를 제한 할 수있는 방법과 느린가 발생한 방식으로 인해 템플릿 언어를 피하는 것입니다.

디자이너가 PHP를 배우는 것이 더 좋습니다. 교대 수업 이름. 또한 장기적으로 더 유용하게 만들 것이며 하나의 구문에서 다른 구문으로 큰 도약이 아닙니다.

당신은 잊었 htmlspecialchars() 두 배. 그렇기 때문에 템플릿 시스템이 필요합니다.

Smarty는 가난합니다. 이를 기반으로 템플릿 시스템을 판단하지 마십시오.

귀하의 분석은 합리적입니다. 나는 다음과 같이 생각한다 :

  • 템플릿 디자이너와 백엔드 프로그래머는 동일하지 않을 수 있으므로 분리를 촉진합니다.
  • 그것은 당신이 템플릿에서 "너무 많은"PHP를 할 수 없다는 점에서 당신을 다소 보호합니다.
  • 일부 시나리오에서 템플릿을 최적화/사전 컴파일하는 것이 더 쉬울 수 있습니까? (이것은 추측입니다)

개인적으로, 나는 그들이 가치있는 것보다 더 번거롭게 생각합니다. 특히 wysiwyg 도구가 무엇을 해야할지 모르기 때문에 템플릿을 "디자이너"에게 건네주고 싶다면 작동하지 않습니다.

내가 보지 못한 템플릿 엔진 장점 중 하나는 ASP.NET Control과 같은 동적 HTML 요소의 가능성이었습니다. 예를 들어, Pear의 HTML 템플릿 Flexy를 사용하면 상태를 자동으로 유지하는 동적 형태 요소를 가질 수 있습니다. 일반 HTML SELECT 요소를 채울 수 있으며 템플릿에서 루프 나 조건부가없는 코드 뒤에 선택한 항목을 설정할 수 있습니다.

클리너 구문은 상당히 큰 승리라고 생각합니다. 비록 몇 캐릭터처럼 보일지 모르지만 매일 할 때 각 캐릭터가 계산하기 시작합니다.

그리고 {$myvar|escape} IMHO는 꽤 짧습니다 <?php echo htmlspecialchars($myvar); ?>. (그것을 명심하십시오 <?=$foo?> 구문은 PHP Conf.에서 특별히 활성화 된 경우에만 사용할 수 있습니다.)

템플릿 엔진을 사용해야한다고 생각하지 않습니다. 대신 당신은 같은 것을 사용해야합니다 Zend_view 프레젠테이션에서 별도의 논리를 수행하도록 장려하지만 PHP에서 프레젠테이션 레이어를 구축 할 수 있습니다.

  • PHP 코드가있는 파일을 템플릿으로 사용하고 싶습니까? 괜찮은.
  • 상기 템플릿에서 변수를 사용하고 싶습니까? 괜찮은.

로직과 최종 출력 (프레젠테이션)을 분리하는 것을 잊지 마십시오. 이것은 템플릿 프레임 워크로 더 잘 수행됩니다. 그러나 당신은 Smarty와 같은 것을 배울 필요가 없습니다.

  • zend_view 또는 이와 유사한 것을 사용하는 경우 PHP 코드를 항상 사용할 수 있습니다.

여기 많은 사람들이 올바른 답변을 가지고 있습니다. Smarty는 PHP에서 템플릿을하지 않습니다. 멀리 떨어져 있습니다. Smarty는 주로 디자이너 (예 : 비 프로그램 제)를 사용하여 페이지 표시를 편집하고 설정 해야하는 사람들을위한 것입니다. 페이지 레이아웃을 변경하는 모든 사람이 프로그래밍 할 수있는 경우 PHP 코드 지향 템플릿 시스템으로 이동할 수 있습니다. 그러나 실제로 모든 출력 데이터를 준비하고 템플릿으로 보내야합니다. 각 페이지가 컨텐츠를 가져오고 처리하고 표시하면 나중에 더 빨리 리팩터링해야합니다.

다른 사람을 위해 코드를 작성할 때. 예를 들어, 한 번은 고객이 사용자 정의 할 수있는 엄격한 웹 애플리케이션 프레임 워크를 만들었습니다. 중요한 요청 중 하나는 고객이 템플릿을 수정하기 위해 디자이너를 고용 할 수 있다는 것입니다. 없이 프로그래밍 할 수 있어야합니다. 더 중요한 것은 그렇지 않을 수도 있습니다 인정 받은 코드를 변경합니다.

예를 들어 Smarty는 템플릿이 수행 할 수있는 일에 대해 상당히 엄격한 제한을 구현할 수 있습니다. 기본적으로, 우리의 응용 프로그램은 가장 기본적인 코드 구성과 선택한 수정 자 기능을 제외한 모든 것을 비활성화했습니다. 그래서 우리는 템플릿 엔진으로 잘 제공되는 두 가지 목표를 가지고있었습니다. 간단 그리고 보안.

그리고 미래를 잊지 말자. 웹 사이트는 거의 게시 된 순간에 오래되었습니다. 어느 시점에서 모양과 느낌을 업데이트해야합니다. 분리를 유지하는 경우 종종 디자이너만으로 백엔드에서 동일한 프로그래밍으로 완전히 새로운 웹 사이트를 완성 할 수 있습니다. 이를 통해 더 빠르고 저렴한 재 설계를 통해 새로운 기능이 필요한 경우 프로그래머 만 참여할 수 있습니다.

일부는 Smarty가 PHP가 이미 할 수있는 일을 수행한다고 주장 할 수도 있습니다. 프레젠테이션을 비즈니스 로직과 분리합니다. PHP 프로그래밍 언어는 코드 개발에 적합하지만 HTML과 혼합 될 때는 PHP 문의 구문이 관리하는 데 엉망이 될 수 있습니다. Smarty는 훨씬 간단한 태그 기반 구문으로 프레젠테이션에서 PHP를 절연하여이를 보완합니다. 태그는 PHP (응용 프로그램) 코드에서 깨끗한 분리를 시행하여 응용 프로그램 내용을 보여줍니다. Smarty Template를 관리하려면 PHP 지식이 필요하지 않습니다.

이 분리의 중요성은 상황입니다. PHP 개발자보다 웹 디자이너에게는 일반적으로 더 중요합니다. 따라서 Smarty는 일반적으로 개발자와 디자이너의 역할이 분리 될 때 적합합니다. 옳고 그른 대답은 없습니다. 모든 개발 팀에는 코드 및 템플릿 관리에 대한 선호도가 있습니다. Smarty는 깨끗한 태그 기반 구문 외에도 표현 데이터 캐싱, 템플릿 상속 및 기능 샌드 박스와 같은 다양한 도구를 제공합니다. 비즈니스 요구 사항과 PHP 코드 Smarty와 함께 사용되고 있습니다. Smarty가 적합한 지 결정하는 데 큰 역할을합니다.

PHP 템플릿 언어가 당신이 그것을 사용하도록 강요 할 정도로 강압적이라면, 당신은 그것을 전혀 사용하지 않을 것입니다. 곤경에 처할 때 '점프'하고 일을하는 능력은 PHP의 매력 중 하나입니다.

나는 그것이 좋은 일이거나 코드가 유지 될 수 있다고 말하지 않습니다. 초기 고려 사항에서는 나를 완전히 차단 한 템플릿 언어를 선택하지 않을 것입니다.

그렇지 않으면 템플릿 시스템이 코딩과 디자인 사이의 작업을 나누고 디자이너 디자인과 코딩을 우리에게 우리에게 나누는 데 도움이된다는 데 동의합니다.

나는 개인적으로 항상 PHP, 파이썬 등에서 템플릿 엔진을 사용합니다.

다른 사람들이 이미 언급 한 첫 번째 명백한 이유 :

템플릿에서 비즈니스 로직을 사용하지 않도록 강요합니다.

그렇습니다. 징계는 당신이 그것을 가질 때 잘할 것입니다.

그러나 이것은입니다 템플릿 엔진을 사용하는 이유의 작은 측면. 그들 중 대부분은 단순한 엔진 이상이며, 당신이 좋아하든 아니든 프레임 워크 템플리트로 간주 될 수 있습니다.

예를 들어, Smarty에는 부분 캐싱과 같은 고급 캐싱 기능이 있습니다. 정말 유용한 것, PHP 만 템플릿 언어로 사용할 때 혼자서해야 할 것들.

그리고 정말 유용한 도우미 기능을 모두 문서에서 빠르게 검색하는 것을 잊지 마십시오. 그들 대부분은 또한 자신의 기능 및/또는 툴킷을 쉽게 연결하는 방법을 제공합니다.

그렇습니다. 선택의 문제입니다. 정말 간단한 템플릿이 필요할 때는 템플릿에서 논리를 유지하는 징계를 보여주는 것을 고려하십시오. 그러나 응용 프로그램이 성장할 것으로 예상되면 결국 템플릿 프레임 워크의 기능이 필요합니다. 그리고 그때까지, 당신은 바퀴를 모두 코딩하여 바퀴를 재창조하지 않기를 바랍니다.

마지막으로, 나에게는 일부 템플릿 프레임 워크에는 하나의 킬러 기능이 있습니다.

템플릿 상속

나는 그것을 알게되었다 장고 그리고 나는 지금 그것을 최신으로 사용하고 있습니다 Smarty 3. 심포니 프레임 워크의 사람들도 가지고 있습니다 작은 가지, Django 구문으로 포트를 고려할 수 있습니다.

처음에는 조금 이상하게 보이지만 매우 강력합니다. 골격을 만들고 다양한 블록을 정의합니다. 해당 골격을 확장하고 콘텐츠로 블록을 채울 수 있습니다.

나를 위해 그것은 골키퍼입니다!

템플릿 관리 시스템을 통해 템플릿 파일을 별도로 관리할 수 있습니다.시스템 실행 시간은 일반 PHP 프로젝트보다 빠릅니다.그래서 여기서는 PHP 파일과 템플릿 파일을 별도로 관리합니다.

파일을 실행하면 코드가 template_c에 저장됩니다.그래서 여러 번 컴파일되지 않습니다.

여러번 이용했어요 작지만 강한, 매우 깔끔하고 간단한 구문을 가지고 있습니다.HTML 템플릿에는 루프나 의사코드가 없습니다.

홈페이지에서:

TinyButstrong은 텍스트 소스를 기반으로 XML/HTML 페이지 및 기타 파일을 동적으로 생성 할 수있는 라이브러리입니다.PHP 언어의 템플릿 엔진입니다.데이터베이스에서 정보를 쉽게 표시 할 수있을뿐만 아니라 PHP 프로그래밍을 심각하게 조화시키고 단순화 할 수 있습니다.

TinyButStrong은 HTML을 지향하지만 Html에 특화되지는 않습니다.즉, 텍스트 파일, XML, RSS, RTF, WML, Excel (XML), ...OPENTBS 플러그인을 사용하면 OpenOffice 및 MS Office 문서를 병합 할 수 있습니다.

java/와 같이 ooops 개념을 많이 사용하는 개발자/Oracle PL-SQL 사람들은 PHP 언어 자체가 엔터프라이즈 레벨 프로젝트에서 프레젠테이션/보기/디스플레이 로직에 사용된다고 말합니다. 이 큰 프로젝트에서 백엔드는 Oracle이고, 데이터베이스는 PL-SLQ/Java를 사용하여 가져오고 프레젠테이션은 PHP입니다. 가장 좋은 예는 Facebook입니다.http://en.wikipedia.org/wiki/facebookFacebook은 프레젠테이션에 PHP를 사용하고 Java/C ++는 백엔드 인터페이스로 사용합니다.

PHP가 HTML과 밀접하게 작동하기 때문에 PHP가 프레젠테이션으로 사용되는 유일한 이유는 있지만 Java/C ++는 더 많은 OOPS 기반이며 HTML에 직접 맞을 수 없습니다. Smarty를 사용하는 CMS (Joomla/Drupal/WordPress) 또는 프레임 워크 (Zend/Symfony/YII)를 알려주세요. 그렇다면 왜 Smarty가 필요합니까?

나는 몇 가지 이유로 템플릿을 사용하는 것을 좋아합니다.

1) PHP 코드의 가독성을 정리합니다. HTML의 덩어리가있는 인쇄 ( "") 문이있을 때 내 PHP 파일이 부풀어 오르고 기발하게됩니다. 또한 변수를 HTML 텍스트에 어떻게 전달합니까? 어디서나 태그를 사용하십니까? print ( "")를 사용하고 HTML 따옴표를 피하고 변수를 연결합니까? print ( "")를 사용하고 HTML에서 단일 따옴표를 사용하여 표준에 대항하여 변수를 직접 삽입합니까?

2) HTML 코드의 프레젠테이션을 정리합니다. 생성 된 HTML이 여러 파일에서 조각으로 해킹되면 생성 된 HTML을 유지하기가 어려워 질 수 있습니다. 예를 들어, 당신의 들여 쓰기는 벗어날 수 있습니다.

3) 여러 템플릿을 만들 수 있으며 로그인 한 사용자는 웹 사이트를 탐색 할 때 표시하려는 템플릿/스킨을 선택할 수 있으며 기본 템플릿을 다른 경우 기본 템플릿을 빠르고 쉽게 변경할 수 있습니다. 경사.

전반적으로, 그것은 모든 것을 조직하는 더 나은 방법 일뿐입니다. 템플릿 클래스 명령, 여러 파일 열기 등을 배우고 입력 해야하는 데는 약간의 트레이드 오프가 있습니다. 그러나 제 생각에는 코드의 가독성과 조직이 증가하기 때문에 그만한 가치가 있다고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top