Potrzebuję bardzo szybkiego i wydajnego systemu szablonów. Zastanawiam się, czy pisać własny, czy przerobić istniejący do potrzeb CMS-a.

Funkcje

• Pętle lub wyciąganie fragmentów. Dla przykładu chcę wyświetlić nowości. Ich ilość na stronie zależy od ustawień. Każdy news ma inne dane. W jaki sposób najlepiej to zrobić? Podobnie jak podpinanie w PDO?

  [PHP] pobierz, plaintext 
  <?php
  $tpl = new Template('file.tpl');
  $tpl -> add('jakaś_zmienna', 'wartość'); //Albo w tablicy
  $block = $tpl -> getBlock('news');
   
  foreach($res as $news)
  {
    $block -> add(...); //Przypisanie zmiennych
    $block -> show(); //Jak zorganizować dane w obiekcie?
  }
  //Albo inaczej - jak?
  ?>
  [PHP] pobierz, plaintext 

  Co do organizacji danych - albo zamiany następują dopiero w metodzie show(), albo przetworzone dane przechowywane są w dodatkowej zmiennej (większe zużycie pamięci RAM). Trzeba zwrócić też uwagę na instrukcje warunkowe i inne operacje.
• Zmienne - prawdopodobnie w stylu {zmienna}. Istotną kwestią jest dostęp do innych zmiennych niż przypisane, choć niekonieczną.
• Instrukcje warunkowe - bez tego trudno napisać elastyczne szablony z dostosowaniem wyglądu do ustawień. Jak je zaimplementować? Może podobnie jak w XT?

  [PHP] pobierz, plaintext 
  <?php
  <div id="jakies_id">zawartość</div>
  ?>
  [PHP] pobierz, plaintext 

  A w PHP coś w stylu:

  [PHP] pobierz, plaintext 
  <?php
  $tpl -> if( TRUE, ...);
  ?>
  [PHP] pobierz, plaintext 

  Nie wiem, czy to dobry przykład. W takich blokach znajdują się jeszcze inne zmienne.
  
  A może coś w stylu PHPTal?

  [PHP] pobierz, plaintext 
  <?php
  <div if="zmienna">...</div>?
  ?>
  [PHP] pobierz, plaintext 

  Na podobnej zasadzie mogą działać pętle.
• Cache - bardzo ważne w celu przyspieszenia skryptu. 2 sposoby:
  - zapis pliku .tpl do .php bądź innej formy
  - zapis przetworzonego szablonu do .html (gdy dane rzadko się zmieniają)
  Jeżeli skrypt dostosowywałby szablony sprawnie, funkcja nie jest konieczna.

Inne bajery są raczej zbędne. Kolejna rzecz - łączny rozmiar podstawowych plików systemu szablonów - maks. 4KB.

Czy opłaca się tworzyć własny system szablonów, czy lepiej wykorzystać już istniejący i dostosować go (np. usunąć zbędne funkcje i instrukcje)? Zastanawiam się nad XT.

Jeśli chodzi o suche fakty:
nic nie będziesz szybsze od czystego php...
jeśli korzystasz z MVC to masz sobie V i tam ładuj klasy i funkcję i wszystko co chcesz
podobnie jak w dokumentacji SMARTY to opisali jeśli jesteś purystą i szablony mają być wolne od kodu to możesz tak zrobić... a jak chcesz władować tam trochę logiki (ale tylko i wyłącznie logiki wyświetlania, inaczej to traci sens) to wolna droga... w php możesz tak samo
pseudo - argument: grafik musi się uczyć PHP, tak to musi uczyć się SMARTY-ów czy innego szablonu, zasadniczo zbyt trudne to nie jest z php

[PHP] pobierz, plaintext 
<?php
class ArticleView
{
	public function nazwaSzablonu()
	{
		//kod
	}
}
?>
[PHP] pobierz, plaintext 

zamiast nazywać pliki nazwie sobie funkcję...
w SMARTY-ach include, w PHP include w SMARTY-ach foreach ...
jak nauczysz się SMARTY-ów to nie ma powodu dla którego nie miałbyś się nauczyć PHP

argument: a jak grafik coś spieprzy to cały skrypt się wyłoży
zrób sobie "panel grafika" bardzo proste rozwiązanie
grafik zrzuca plik gdzieś na serw, a nie do szablonów
i odpala sobie swój panel, pokazuję plik który chce podmienić PHP otwiera go i na końcu dopisuję za klasą kod return TRUE;
jeśli wynik eval będzie TRUE znaczy że nie ma w nim błędów czy coś podobnego i aplikacja raczej nie ma prawa się już wyłożyć, a skrypt może zapisywać poprzednią kopię gdzieś, i jeśli grafik stwierdzi sam naocznie że coś szablon niezupełnie działa jak powinien, podmienić przez skrypt z powrotem

nie wiem jakie jeszcze argumenty były przeciw czystemu PHP ale jak sobie to przemyślałem to wydały mi się bezsensowne

System szablonów xt mi się w sumie spodobał jak o nim przeczytałem, trudno go nazwać pseudo-kodem jednak też ma te swoje magiczne klasy czy inne bajery (już dokładnie nie pamiętam), jednak grafik musi dobrze wtedy znać xhtml i css, a to nie u wszystkich jest oczywiste, nie wspominając o xslt które chyba xt wspiera bądź miał wspierać, poza tym obawiam się że parsowanie tych szablonów będzie dosyć czasochłonne, przelecieć wszystko css-em (a masz 2 opcję albo skomplikowane regułki albo od ... id-ów, co w efekcie sprawi że niemal wpisałeś w dane miejsce nazwę zmienną), na stronie xt piszą że ich strona jest generowana właśnie tymi szablonami, czasy trzeba przyznać krótkie ale te strony są niemal statyczne, to nawet specjalnie nie ma czego parsować
a boję się myśleć gdyby ktoś przez przypadek usunął jakiś znacznik otwierający czy zamykający
albo głupi znak > w php to masz debbugera a xt? zapewne odpalisz sobie szablony potem w jakiejś mozilli lub czymś takim i zobaczysz gdzie w kodzie kolorki się zmieniają... ale wg mnie xt choć jest bardzo rozwiązaniem, to chyba mało bawiłoby mnie jego używanie, mam pewne wątpliwości co do czasów generowania i elastyczności tego rozwiązania, ale nie używałem xt więc wypowiadać się nie mogę...

to by było moje zdanie

PS. sporo topiców było na ten temat ostatnio chyba @deirathe rozpoczął podobny (jeśli coś przekręciłem to przepraszam)

PS2. wszyscy piszą potrzebują baaaaaaaaaaaaaardzo wydajnego i szybkiego czegoś, a bądź co bądź większość ich nie potrzebuje...

Nic nie będzie szybsze od czystego PHP - prawda. Ja zawsze jednak używam Smarty. Ale to może tylko z przyzwyczajenia... Mnie się podoba.

Smarty przecież przetwarza z znaczników na kod PHP, więc właściwie jedyny narzut to spr. czy plik szablony jest zmieniony (co można regulować), no i oczywiście jakość kodu, ale tu jest niewiele do robienia, więc nie zrobi nam złego algorytmu

EDIT:
Do tego łatwiej pojąć osobą {$cos} niż <?php echo $coś ?>, czy warunki itp., do tego sam system szablonów pilnuje czy jest prawidłowe użycie znaczników...

Smarty jest popularne przy tworzeniu stron WWW... Dlatego jest też często znane przez grafików, którzy robią dla Ciebie jakieś zlecenie... Jeśli grafik jest naprawdę dobry, zna też podstawy PHP, ale nie o tym mowa w topicu.

Powiem Ci z własnego doświadczenia...
Pisząc własną klasę do obsługi szablonów możesz sobie zrobić z nią co chcesz, jednak jej udoskonalenie, dostosowanie i zuniwersalizaja potrwają sporo czasu do ogólnego stosowania w Twoich różnych projektach // jeśli się tym zajmujesz na co dzień//

Używając gotowe systemy szablonów jak Smarty czy xt, zawsze możesz sobie dorobić/zmienić w nich conieco.

Osobiście korzystam ze Smarty, do którego z każdym projektam, gdy jest potrzeba dodaje nowe plug-in'y, tak aby ułatwić życie sobie i mojemu stałemu grafikowi, który zna już modyfikacje.
W każdym razie nawet jeśli zna tylko podstawy Smarty, to całą resztę mogę już sam dorobić... W końcu on zajmuje się głównie HTML'em oraz CSS'em.

Oczywiście czysty kod PHP jest najszybszy, ale... ale późniejsza modyfikacja serwisu/strony jest po prostu straszne...

przyznam szczerze, że weteranem w bojach z systemami szablonów to ja nie jestem, zasadniczo to ich nie lubię po prostu, wiadomo każdy ma swoje zdanie, czas pokażę może się przekonam

aczkolwiek co do czasu i SMARTY-ów z tego co mi kiedyś znajomy opowiadał to SMARTY zajmowały ~ 90% czasu wykonywania się skryptu z wyjątkiem operacji I/O, więc albo w skrypcie nie było logiki co byłoby dziwne :P albo SMARTY, nie wiem nie wypowiadam się
w każdym razie nie przepadam


@Sedziwoj no nie rób z ludzi ćwierćinteligentów , no chyba że chcesz się pochwalić ile zajęło Ci zrozumienie tej kwestii (taki żarcik )
bądź co bądź tu nie ma nic do myślenia if-y jakoś masakrycznie też się nie różnią
tu nie ma mowy o sekundach nauki dłużej niż w SMARTY-ach (przynajmniej ja nie widzę takiej potrzeby), jak się uczysz nowego języka programowania to patrzysz jak wyglądają struktury kontrolne, pętle, inicjalizacja zmiennych, definicja funkcji, klas, procedur (czy co tam jest) i jedziesz, przecież nie wynajdujesz koła od nowa...
nie wiem czy znasz python-a czy nie (ja nie znam :P) ale czy obsługi if-a uczyłbyś się krócej niż w PHP/Javie/C bo w nim przy if-ie nawiasów nie otwierasz i nie zamykasz?
powiedziałbyś że jest trochę więcej pisania... no to ok, zgadzam się..., ale że trudniej to pojąć? tak jakbyś powiedział mi że kupiłeś nowy TV masz nowego pilota, na nim obrazki "te same ale trochę inne" (bo różnią się wielkością kolorem itp.) albo same przyciski innego kształtu i z tego powodu już ich wcisnąć nie potrafisz albo trudniej Ci pojąć jak wcisnąć...

co do pytania autora wątku na które zapomniałem odpowiedzieć: moim zdaniem zdecydowanie nie ma sensu pisać własnego systemu szablonów, zresztą jak już się czepiać tak tej nauki to powiedz mi kto specjalnie pod projekty z Tobą będzie się uczył Twojego systemu :P, chyba że masz ambicje wybić się nad SMARTY
systemy są proste i złożone, modyfikowalne i w ogóle cudowne ;D:P, tak jak sobie pomyśleć trochę bezsensu to wygląda w PHP jeśli chodzi o wykorzystywanie czegoś co zostało już napisane..., w Ruby-m wszyscy tworzą na Ruby on Rails, w Javie korzysta się ze źródeł i są też pojedyncze (z tego co mi wiadomo) frameworki jak Eclipse, ale tam to już jest doszlifowane i spokój, a w PHP każdy ma swoje szablony, swoje frameworki, swoje wszystko :P


Wydaję mi się, że to czy kod jest straszny do edycji zależy tylko od tego jak ten kod był tworzony, jak się piszę w sposób zagmatwany to wiadomo że jak to zamkniesz i otworzysz też będzie zagmatwane :P
nie widzę powodu dla którego sensownie prowadzony kod miałby być cięższy do edycji niż szablon, jeszcze jeśli będzie jakieś dobre środowisko pracy, które wylistuję wszystkie metody klasy które stanowiłyby kolejne szablony ale to już taki OT

@zimi
Nie powtarzaj głupot o Smarty, czas wykonania jest pomijalnie mały. Robiłem nie raz profilowanie aplikacji i najczęściej aoutloader zajmuje najwięcej, czy połączenie z bazą danych (jak się łączy z kiepskim serwerem)

Co do nauki, to ja nie mówię o sobie, tych rzeczy powinna nauczyć się osoba która twoży wygląd strony, a dla ona nie musi znać żadnego języka programowania.

Dobra, zgoda, ale trzeba się zastanowić po co są szablony. Chodzi o oddzielenie warstwy biznesowej od warstwy prezentacji w aplikacji (tak to się chyba nazywa ). W czystym PHP też się da, ale nie tak... "ładnie". Poza tym - widziałeś kiedyś kod np. osCommerce? Z pewnym przymrużeniem oka można powiedzieć, że jest on w miarę "sensownie prowadzony". A ja ostatnio przerabiam to coś i klient zażyczył sobie "możliwość dynamicznego wgrania szablonów". Tak żeby można było mając jakiś layout pracować przy okazji nad innym i potem od razu go wgrać (bez przestojów i czasowego wyłączania serwisu). Idea fajna, z wykonaniem gorzej. Hipotetyczny grafik (designer), który by to robił, musiałby pracować na całym osCommerce (czyli jakoś tam wiedzieć co to PHP i do czego). Albo ja musiałbym wszystko przerabiać na Smarty, co jest wykonalne, ale jakby to... rzygać mi się chce na samą myśl.

Jeśli już oddzielać logikę od wyglądu to raczej używając szablonów, bo inaczej tworzy się bałagan (wtedy najlepiej wszystko objąć instrukcją ECHO). Jeszcze gdyby wystarczyło wstawić same zmienne <?= $zmienna ?> to w porządku, lecz dochodzą jeszcze instrukcje warunkowe i pętle.

Trochę inna sytuacja jest z pętlami. Rekordy z bazy danych pobieram na bieżąco:

[PHP] pobierz, plaintext 
<?php
foreach($res as $news)
{
  ...
}
?>
[PHP] pobierz, plaintext 

Metoda bardzo szybka w przeciwieństwie do buforowania danych i użycia innej pętli.

Smarty to obszerny skrypt. Można powiedzieć, że implementuje własny język. Podstawowe pliki: 61 KB (główny), 90 KB (kompilator), w core.funkcje (44 KB) to już 145 KB. Po spakowaniu do ZIP-a rozmiar pewnie nie będzie duży. Rzecz jednak w tym, że w przypadku szybkiego i lekkiego systemu CMS nie ma potrzeby ładować do pamięci funkcji, które na 98% nie zostaną wykorzystane w szablonach.

Wolę system szablonów, który nie narzuca zbytnio własnej składni (oprócz podstawowych instrukcji). Co jeszcze możecie mi polecić? Wciąż ważna jest szybkość.

Jeżeli jesteśmy przy Smarty, podobnym systemem jest polski OPT - również obszerny.

http://pornel.net/szablony
PHPTal też ma własną składnię, lecz jest bardziej przejrzysty. Co do Smarty i OPT - jeśli pisze się czytelnie, nie powinno być bałaganu.