Dlaczego powinienem używać systemu szablonów w PHP?

Głównym powodem, dla którego ludzie używają systemów szablonów, jest oddzielenie logiki od prezentacji. Jest z tego wiele korzyści.

Po pierwsze, możesz przekazać szablon projektantowi stron internetowych, który może przenosić rzeczy według własnego uznania, bez martwienia się o utrzymanie przepływu kodu. Nie muszą rozumieć PHP, tylko wiedzieć, aby pozostawić specjalne tagi w spokoju. Być może będą musieli nauczyć się kilku prostych semantyki dla kilku tagów, ale jest to o wiele prostsze niż uczenie się cały język.

Ponadto, dzieląc stronę na osobne pliki, zarówno programista, jak i projektant mogą pracować na tej samej "stronie" jednocześnie, sprawdzając kontrolę źródła w razie potrzeby, bez konfliktów. Projektanci mogą testować wizualizacje szablonów na podstawie stabilnej wersji kodu, podczas gdy programista dokonuje innych, potencjalnie łamiących zmiany, na podstawie własnej kopii. Ale jeśli obie osoby edytowały ten sam plik i musiały scalić się w różnych zmianach, możesz napotkać problemy.

Wymusza również dobre praktyki programistyczne w utrzymywaniu logiki biznesowej z dala od logiki prezentacji. Jeśli umieścisz swoją logikę biznesową zmieszaną z prezentacją, to masz trudniejszy czas na jej wyodrębnienie, jeśli musisz później przedstawić ją inaczej. W dzisiejszych czasach coraz większą popularnością cieszą się różne tryby prezentacji w aplikacjach internetowych: kanały RSS/ATOM, odpowiedzi JSON czy AJAX, WML dla urządzeń przenośnych itp. Z systemem szablonów często można to zrobić w całości za pomocą szablon i brak lub mała zmiana na cokolwiek innego.

Nie każdy jednak będzie potrzebował lub docenił te korzyści. Zaletą PHP nad Javą / Python / Ruby / etc jest to, że można szybko zhakować strony internetowe z pewną logiką w nich, i to wszystko dobrze i dobrze.

Używanie szablonów innych niż PHP z wymówką oddzielania logiki jest nonsensem. Jeśli deweloper nie rozumie, czym jest oddzielenie logiczne widoku biznesowego i jak należy to zrobić, problem musi zostać odpowiednio rozwiązany. W przeciwnym razie skończysz z HTML w logice biznesowej lub logiki biznesowej w szablonach - żaden silnik szablonów cię nie uratuje. Musisz nauczyć dewelopera podstaw.

I jeśli programista zrozumie to, system szablonów jest tylko ograniczenie. Nie dodaje żadnej wartości do procesu programowania, tylko narzuty na naukę nowej składni, utrzymywanie aktualizacji innej biblioteki i wolniejsze wykonywanie. Podczas gdy ten ostatni może być rozwiązany z buforowania i tym podobne, to tylko rozwiązuje problem, który w przeciwnym razie nie istnieje. Tak więc systemy szablonów nie oferują żadnej wartości, żadnej korzyści.

Jest jednak jeden wyjątek, w którym uważam, że używanie szablonów innych niż PHP jest rozsądne: gdy programiści view-logic muszą mają ograniczony dostęp do szablonów. Na przykład, jeśli jesteś dostawcą systemu hostingu blogów i chcesz zezwolić użytkownikom na personalizację i kodowanie szablonów, nie pozwalając im na wykonywanie dowolnego kodu. Argument ten jednak nie ma zastosowania do przypadków, w których projektant jest skłonny nauczyć się trochę kodu, aby pomóc w programowaniu interfejsu użytkownika. Jeśli potrafi nauczyć się Smarty ' ego, może z pewnością nauczyć się PHP.

Nadal istnieje dobry powód, aby używać systemu szablonów, jednak nie Smarty, ale PHPTAL . Szablony PHPTAL są poprawnymi plikami XML (a więc XHTML). Możesz dalej używać atrapy zawartości w PHPTAL i tak uzyskać poprawny plik XHTML z ostatecznym wyglądem, który może być przetwarzany i testowany za pomocą standardowych narzędzi. Oto mały przykład:

<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 template engine automatycznie wstawi wszystkie wartości z tablicy użytkowników i zastąpi nasze atrapy wartości. Niemniej jednak tabela jest już poprawny XHTML, który może być wyświetlany w wybranej przez Ciebie przeglądarce.

Dla mnie jedną z dużych cech silników szablonów jest to, że warstwa pamięci podręcznej jest przezroczysta dla Ciebie. Używam smarty dawno temu, a rzeczy cache ułatwiają życie. również projekt smarty pozwala na korzystanie z własnej funkcji pamięci podręcznej. W moim przypadku wybieram, czy dla jakiejś strony należy użyć memcache lub dysku do przechowywania wyjścia szablonu.

Z drugiej strony, jeśli Twoja strona ma duży ruch i nie wiesz, jak zarządzać smarty i dobrze go dostrajać, każdy silnik szablonu może bądź zabójcą strony. ale nawet nie używając smarty Twoja strona może umrzeć.

Flickr używa obecnie smarty. nie powinno być tak źle, prawda?

PHP jest w zasadzie systemem szablonów. Kluczem jest zmuszenie się do samodzielnego oddzielenia logiki od prezentacji. Używanie Smarty lub czegoś takiego tylko sprawia, że nieco bardziej niewygodne jest mieszanie logiki i prezentacji. Jeśli nie możesz samodzielnie ich rozdzielić, użycie systemu szablonów nie pomoże. To tylko pochłonie dodatkową moc obliczeniową.

Kluczem jest, aby nie zmieniać żadnych wartości w kodzie prezentacji. Aby to zrobić, ja pomyśl, że samo PHP jest tak samo skuteczne jak Smarty, jeśli używasz składni if / endif:

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

Głównie myślę, aby uniknąć "niebezpiecznej" logiki backendu, która ma być zastosowana w szablonach. Ponieważ większość szablonów jest przekazywana projektantom, chcemy tylko dać im zamknięty zestaw rzeczy, które mogą zrobić.

Podoba mi się możliwość trywialnego wyświetlania dowolnego szablonu z dowolnego pliku PHP (i dołączania fragmentów szablonów wewnątrz siebie, dla wspólnych elementów, takich jak paski nav). Załóżmy na przykład, że masz stronę, która normalnie wyświetla pewne informacje, jeśli jesteś zalogowany, lub błąd, jeśli nie jesteś. Z PHP piszesz coś w stylu:

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

W Smarty może być coś takiego (wybacz moją chyba złą składnię, minęło trochę czasu):

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

Gdybyś był naprawdę sprytny, może nawet wyświetlać szablon strony logowania zamiast szablonu błędu, opcjonalnie z Komunikatem wyjaśniającym, dlaczego użytkownik tam trafił. A jeśli poszedłeś z techniką, jak to napisałem, a następnie zdecydowałeś, że chcesz przełączyć się na wyświetlanie pola logowania, to tylko jedna zmiana linii! Dla mnie nie chodzi tylko o zachowanie separacji widoku od logiki, ale o możliwość ponownego wykorzystania wspólnych elementów widoku z wielu miejsc.

Cieszę się, że używam frameworka MVC, takiego jak code igniter. Uważam, że w "widokach" mam tendencję do trzymania się kodu php, który odnosi się tylko do tego, jak wartości są wyświetlane. Mam bibliotekę funkcji formatowania, które mogę wykorzystać w widokach w tym celu. Jednym z założeń programu code igniter jest unikanie języka szablonów ze względu na sposób, w jaki może on cię ograniczać i spowolnić.

Uważam, że lepiej jest dla projektantów nauczyć się trochę PHP, aby mogli osiągnąć to, co muszą zrobić np. zmienne nazwy klas. To również uczyni je bardziej użytecznymi w dłuższej perspektywie i nie jest to ogromny skok z jednej składni do drugiej.

Zapomniałeś dwa razy. Dlatego potrzebujesz systemu szablonów.

Twoja analiza jest rozsądna. Chyba:

• projektanci szablonów i Programiści zaplecza mogą nie być jednym w tym samym, więc sprzyja to separacji.
• chroni Cię nieco przed samym sobą, ponieważ nie możesz zrobić "za dużo" PHP w swoich szablonach.
• może być łatwiej zoptymalizować / wstępnie skompilować szablony w niektórych scenariuszach? (To spekulacje)

Osobiście uważam, że są bardziej kłopotliwe niż warte. Szczególnie nie działają, jeśli chcesz ręka szablony do "projektantów", ponieważ narzędzia WYSIWYG nie wiedzą, co z nimi zrobić.

Jedną z zalet silnika szablonów, której nie widziałem, była możliwość dynamicznych elementów html - coś w rodzaju asp.net sterowanie. Na przykład, dzięki szablonowi HTML Pear flexy możesz mieć dynamiczne elementy formularza, które automatycznie zachowują stan. Zwykły element html select może być wypełniony i mieć zaznaczony element ustawiony w kodzie za bez pętli lub warunków w szablonie.

Myślę, że czystsza składnia to dość duża wygrana. Chociaż może to wyglądać tylko kilka znaków, ale kiedy robisz to codziennie, wtedy każda postać zaczyna się liczyć.

I {$myvar|escape} jest IMHO nieco krótszy od <?php echo htmlspecialchars($myvar); ?>. (Pamiętając, że składnia <?=$foo?> jest dostępna tylko wtedy, gdy jest specjalnie włączona w PHP conf.)

Myślę, że nie powinieneś używać silnika szablonów. Zamiast tego powinieneś użyć czegoś w rodzaju Zend_View , co zachęca do oddzielenia logiki od prezentacji, ale pozwala Ci zbudować warstwę prezentacji w PHP.

• chcesz użyć pliku z kodem PHP jako szablonu? Dobrze.
• chcesz użyć zmiennych we wspomnianym szablonie? Dobrze.

Pamiętaj tylko, aby oddzielić logikę i końcowe wyjście (prezentację). Jest to lepiej realizowane za pomocą frameworku szablonowego. Ale nie musisz się uczyć czegoś takiego jak Smarty.

• Jeśli używasz Zend_View lub podobnego, możesz używać kodu PHP do końca.

Wiele osób tutaj ma poprawną odpowiedź. Smarty nie jest szablonem w PHP. Daleko mi do tego. Smarty jest głównie dla tych, którzy muszą używać projektantów (tj. nie-programistów) do edycji i konfiguracji wyświetlania stron. Jeśli każdy, kto zamierza zmienić układ twoich Stron, może programować, możesz wybrać bardziej zorientowany na kod PHP system szablonów. Ale naprawdę powinieneś mieć wszystkie dane wyjściowe gotowe i wysłać je do szablonu. Jeśli pozwolisz każdej stronie pobrać, przetworzyć i wyświetlić zawartość, będziesz musiał ją refaktorować wcześniej niż później.

Kiedy piszesz kod dla kogoś innego. Na przykład byłem kiedyś zaangażowany w tworzenie sztywnego frameworka aplikacji webowych, który powinien być konfigurowalny dla naszych klientów. Jedną z ważnych próśb było to, aby klient mógł zatrudnić projektanta do modyfikacji szablonów bez konieczności programowania. Co ważniejsze, może nie być upoważniony do zmiany kodu.

Smarty na przykład pozwala wdrożyć dość sztywne ograniczenia co szablon może zrób. Zasadniczo, nasza aplikacja wyłączyła wszystkie, ale najbardziej podstawowe konstrukcje kodu i wybrany zestaw funkcji modyfikujących. Mieliśmy więc dwa cele, które były dobrze obsługiwane przez silnik szablonów: prostota i bezpieczeństwo.

I nie zapominajmy o przyszłości. Strony internetowe są stare prawie w momencie ich opublikowania. W pewnym momencie będziesz musiał zaktualizować wygląd. Jeśli często utrzymujesz separację, sam projektant może ukończyć zupełnie nową stronę internetową z tym samym programowaniem na zapleczu. Pozwala to na szybsze i tańsze przeprojektowanie, pozwalając na zaangażowanie programisty tylko wtedy, gdy wymagana jest nowa funkcjonalność.

Niektórzy mogą twierdzić, że Smarty robi to, co PHP może już zrobić: oddzielić prezentację od logiki biznesowej. Język programowania PHP jest świetny do tworzenia kodu, ale po zmieszaniu z HTML, składnia instrukcji PHP może być bałagan do zarządzania. Smarty nadrabia to izolując PHP od prezentacji za pomocą znacznie prostszej składni opartej na znacznikach. Znaczniki ujawniają zawartość aplikacji, wymuszając czyste oddzielenie od kodu PHP (aplikacji). Do zarządzania Smarty nie jest wymagana znajomość PHP szablony.

Znaczenie tego podziału jest sytuacyjne. Jest to zwykle ważniejsze dla projektantów stron internetowych niż dla programistów PHP. Dlatego Smarty jest zwykle dobrym rozwiązaniem, gdy role programistów i projektantów są rozdzielone. Nie ma właściwej lub złej odpowiedzi: każdy zespół programistów ma swoje własne preferencje dotyczące zarządzania kodem i szablonami. Oprócz czystej składni opartej na znacznikach, Smarty oferuje również szeroką gamę narzędzi do zarządzania prezentacją: ziarniste buforowanie danych, dziedziczenie szablonów i funkcjonalne piaskownice, aby wymienić tylko kilka. Wymagania biznesowe i kod PHP Smarty jest używany z Będzie odgrywać dużą rolę w określaniu, czy Smarty jest dobre dopasowanie.

Założę się, że gdyby język szablonów PHP był tak przymusowy, że zmusiłby Cię do użycia go, w ogóle byś go nie używał. Możliwość "wyskoczenia" i robienia rzeczy po swojemu, gdy masz kłopoty, jest jedną z atrakcyjnych cech PHP.

Nie mówię, że to dobrze, ani że kod będzie możliwy do utrzymania, tylko, że w początkowych rozważaniach nie wybrałbym języka szablonów, który całkowicie mnie zablokował.

W Przeciwnym Razie zgadzam się, że systemy szablonów pomagają dzielić pracę między kodowanie i projektowanie, i ewentualnie pozwalając projektantom projektować i kodować nam.

Ja osobiście zawsze używam silników szablonowych w php, Pythonie czy czymkolwiek innym.

Pierwszy oczywisty powód już wspomniany przez innych:

To zmusza do nie używania żadnej logiki biznesowej w szablonach.

Jasne, dyscyplina by się przydała, gdy ją masz.

Ale to jest tylko mały aspekt, dlaczego miałbyś używać silnika szablonów. Większość z nich to coś więcej niż tylko silnik i można je uznać za frameworki szablonowe, czy czy ci się to podoba czy nie.

Na przykład Smarty ma również zaawansowane funkcje buforowania, takie jak buforowanie częściowe. Naprawdę przydatne rzeczy, rzeczy, które musisz zrobić sam, gdy używasz tylko php jako języka szablonów.

I nie zapomnij o wszystkich tych naprawdę przydatnych funkcjach pomocniczych, wystarczy szybkie wyszukiwanie w dokumentach. Większość z nich zapewnia również łatwy sposób podłączenia własnych funkcji i/lub zestawu narzędzi.

Więc tak, to kwestia wyboru. Gdy potrzeba naprawdę prostych szablony, rozważ pokazanie dyscypliny a trzymaj logikę z dala od szablonów. Ale kiedy spodziewasz się, że Twoja aplikacja będzie się rozwijać, w końcu będziesz potrzebować funkcji szablonu framework. A do tego czasu, mam nadzieję, że nie odkryjesz koła, kodując je wszystkie swoje.

I wreszcie, dla mnie jest jedna zabójcza funkcja dostępna w niektórych frameworkach szablonowych.

Dziedziczenie Szablonów

I ' ve came to know it from Django i używam go teraz w najnowszym Smarty 3 . Chłopaki z Symphony Framework mają również gałązkę , którą można rozważyć jako port ze składnią Django.

Na początku wygląda trochę dziwnie, ale jest niezwykle potężny. Budujesz swój szkielet i definiujesz różne bloki. Możesz rozszerzyć taki szkielet i wypełnić (nadpisać) bloki swoją zawartością.

Dla mnie to Stróż!

System zarządzania szablonami, możemy zarządzać plikami szablonów oddzielnie. czas wykonania systemu będzie szybszy niż normalny projekt PHP. więc tutaj Pliki PHP i pliki szablonów są oddzielnie utrzymywane.

Po uruchomieniu plików kod zostanie zapisany to template_c. więc nie jest kompilowany wiele razy.

Kilka razy użyłem tinybutstrong , który ma dość zgrabną i prostą składnię. Brak pętli lub pseudokodów w szablonie html.

Ze strony głównej:

TinyButStrong to biblioteka, która umożliwia dynamiczne tworzenie Strony XML / HTML i wszelkie inne pliki oparte na źródle tekstu. To jest Silnik szablonów dla języka PHP. Umożliwia łatwe wyświetlanie informacji z bazy danych, ale także do poważnego ujednolicenia i Uprość swoje PHP programowanie.

TinyButStrong jest zorientowany na HTML, ale nie wyspecjalizowany do Html. To oznacza, że może pracować również z plikami tekstowymi, XML, RSS, RTF, WML, Excel (xml),.. Wtyczka OpenTBS umożliwia łączenie OpenOffice I Ms Dokumenty biurowe.

Programiści, którzy będą intensywnie korzystać z koncepcji Oops, takich jak JAVA / Spring / Oracle PL-SQL ludzie, mówią, że sam język PHP jest używany do prezentacji/wyświetlania / wyświetlania logiki w projektach na poziomie korporacyjnym. W tych dużych projektach zapleczem jest Oracle, baza danych jest pobierana za pomocą pl-slq / java, a prezentacja to php.Najlepszym przykładem jest facebook. http://en.wikipedia.org/wiki/Facebook facebook używa php do prezentacji, java / c++ jako interfejsu backendowego.

The only powód PHP jest używany jako prezentacja, ponieważ ściśle współpracuje z HTML, ale java / c++ jest bardziej oparta na OOPs I nie może pasować bezpośrednio do HTML. Powiedz mi jeden CMS (joomla/drupal/wordpress) lub framework (ZEND/symfony / Yii) który wykorzystuje Smarty? Dlaczego smarty jest potrzebny?

Lubię używać szablonów z kilku powodów:

1) czyści czytelność kodu PHP. Moje pliki PHP stają się nadęte i niewdzięczne, gdy wszędzie są instrukcje print("") z kawałkami HTML. Pojawiają się również problemy, takie jak przekazywanie zmiennych do tekstu HTML? Używasz wszędzie znaczników? Czy używasz print ( "" ) i unikasz cudzysłowów HTML i łączysz swoje zmienne? Czy używasz print ( "" ) i używasz pojedynczych cudzysłowów w HTML, idąc wbrew standardowi i wstawiając Twoje zmienne bezpośrednio?

2) czyści prezentację kodu HTML. Może być trudno utrzymać wygenerowany HTML dobrze wyglądający, jeśli zostanie pocięty i zhakowany na kawałki w wielu plikach. Na przykład, Twoje wcięcia mogą się oderwać.

3) pozwala na tworzenie wielu szablonów, a następnie zalogowany użytkownik może wybrać, który szablon / skórkę chce wyświetlić podczas przeglądania witryny, a także szybko i bez wysiłku zmienić domyślny szablon na coś inaczej, jeśli jesteś taka skłonna.

Ogólnie rzecz biorąc, to po prostu lepszy sposób na zorganizowanie wszystkiego. Jest trochę kompromisu w konieczności uczenia się i wpisywania poleceń klasy szablonu, otwierania wielu plików itp. Ale moim zdaniem warto, bo czytelność i organizacja kodu idzie w górę.