Witam,

Chciałbym się dowiedzieć do czego służą szablony open power template lub smarty lub też jakieś inne podobne do tych co wymieniłem wcześniej.

Uczę się ich dopiero i tak jak prubóję sobie je zastosować do swoich skryptów to mi się wydaje że one jednak utrudniają życie. Nie eleminują całkowicie kod PHP w szablonach. Dodatkowo trzeba się uczyć składni danego szablonu(oczywiście nie mówię że mi się nie chce uczyć czegoś nowego bo to nie prawda tylko lepiej się uczyć jak wiesz po co ci to będzie.).

Czytałem wiele wypowiedzi na ten temat ale jakoś nie znalazłem rozsądnej która będzie do mnie przemawiała.

Dziękuję za odpowiedzi Pozdrawiam.

Bo eliminacja PHP z szablonów nie jest celem systemów szablonów. Ich celem jest oddzielenie prezentacji danych w formacie HTML od pozostałej części aplikacji a to, w jakim języku sobie tę prezentację zaklepiesz, nie ma już dla samej idei żadnego znaczenia - ostatecznie istnieje przecież sporo systemów szablonów, które wykorzystują PHP do ich pisania.

Po co separować: aby zwiększyć niezawodność i poprawić podatność na modyfikacje. Kod HTML to zazwyczaj najczęściej poddawany przeróbkom element kodu, zwłaszcza w końcowej fazie tworzenia projektów, gdzie klienci często chcą, by im coś zamienić miejscami, albo gdzieś dodać gwiazdkę. Czemu masz ryzykować przy tej okazji rozwalenie jakiegoś algorytmu przetwarzania danych? Ponadto możesz zmienić szatę graficzną bez przepisywania całego kodu na nowo - wystarczy, że napiszesz nowe szablony. Poprawia to także ogólną czytelność kodu; mi osobiście dużo wygodniej pisze się kod systemu, gdy nie plączą mi się wokół znaczniki HTML, tylko całe wyświetlanie mam obsłużone w oddzielnej warstwie.

Tak więc nie mów, że one utrudniają życie, bo korzystają z nich niemal wszyscy poważni programiści nawet, jeśli się do tego nie przyznają. To, co napisałeś, że system szablonów = oddzielny język, to jedna z największych bzdur, jakie można wygłosić na temat tego typu bibliotek.

Natomiast co do samych języków szablonów - stworzyć dobry język do tworzenia szablonów jest cholernie trudno, dlatego primo mało jest systemów szablonów, które realizują to przyzwoicie, a secundo - ponieważ dużo systemów ma ten element skopany, wielu programistów ich nie lubi. We frameworkach idzie się najczęściej po najmniejszej linii oporu i wstawia system oparty o szablony PHP, głównie dlatego, że autorzy mają na głowie cały framework i po prostu nie mają czasu, by siedzieć i dobrze opracowywać tylko ten konkretny element. Nie da się jednoznacznie wskazać, który wybór jest lepszy, ponieważ nie mamy obiektywnej miary do porównań. Na pewno mogę powiedzieć, że używanie systemów szablonów, które reimplementują PHP (np. Smarty) mija się z celem z kilku powodów:
- Taki język to najczęściej podzbiór PHP, czyli posiada jedynie część funkcjonalności PHP.
- To, co da się zrobić w takim Smartym, da się zazwyczaj dokładnie tak samo zakodować w PHP, czyli poza zmianą składni nic nie zyskujemy.
- Ale to, co da się zakodować prosto w PHP, a jest przydatne w szablonach, nie zawsze da się prosto zrobić w Smartym.
- Czasami autorzy w dodatku wprowadzają jakąś ezoteryczną składnię (np. modyfikatory Smarty'ego - po kija to jest, kiedy cały świat używa i rozumie zapis funkcja(argumenty)?!)

W przypadku prostych systemów szablonów, których autorzy argumentują, że "nie potrzebują takiej kobyły", powstają jeszcze większe paradoksy, bo język jest tak okrojony, że wykłada się na najprostszych problemach .

Należy być świadomym, że PHP samo w sobie też nie jest idealne. Każdy język posiada wady, PHP również. Przede wszystkim odniosę się do argumentu o konieczności "uczenia się", który też swoją drogą jest kompletnym bezsensem. Aby PHP dało się znośnie używać przy tworzeniu szablonów, (bo język sam w sobie jest goły, jak mysz kościelna) musisz do niego dodać kupę rozmaitych helperów, które nierzadko są ekstremalnie wręcz skomplikowane, jeśli chodzi o konfigurowanie i dostosowywanie ich do swoich potrzeb (ciężka obiektówka, złożone wzorce projektowe i te sprawy). Ich też się trzeba nauczyć. Dla mnie osobiście jest on bardzo mało elastyczny, jeśli chodzi o generowanie kodu HTML i wybitnie nieczytelny, zwłaszcza gdy się próbuje coś bardziej skomplikowanego zrobić.

Moje zdanie jest takie, że jak już tworzyć nowy język, to naprawdę z pomysłem, by to rzeczywiście było coś innego, niż "PHP w klamerkach", prezentującego inną filozofię projektowania szablonów, rozwiązywania określonych problemów itd. A jakie konkretnie podejście Ci bardziej spasuje, to już musisz sam sprawdzić.

No tak, ale np: co się tyczy zmieniania wyglądu strony na potrzeby klienta to można stworzyć katalog templates i w nim umieszczać wszystkie pliki.html lub *.php które będą wyświetlały zawartość strony, grafikę itp.

Nie wiem czy ten pomysł jest dobry ale ja go osobiścię stosuję.

Smarty stosujesz po to, żeby (przynajmniej ideowo, i jeśli jesteś dobry to tak Ci się uda zrobić) całkowicie oddzielić PHP od kodu HTML. Bardzo mi się to przydało przy współpracy z grafikiem, gdyż nie wchodziliśmy sobie w paradę, kolega zajmował się katalogiem templates, a ja całą resztą. A takto wyobrazasz sobie, że dajesz kod php mix html grafikowi i on przez przypadek coś zmieni i klops!
taki przykład, poza tym takto możesz bardzo fajnie zmieniać style (np. świąteczny, wiosenny, ...) bez ingerencji w kod
ja widzę jeszcze więcej zalet smartów, ale nie chcę tu pisać subiektywnego eseju

@piotr94: akurat to wszystko co opisałeś można dokładnie tak samo uzyskać z i bez Smarty.

No właśnie, zgadzam się z Crozin i dla tego właśnie pytam. Po co dokładnie są te smarty. A jeśli chodzi o grafika to on też musi znać podstawy php i jak działają szablony.

nie chodziło mi tu konkretnie o smarty, ale o ogólne stosowanie szablonów. W ostatnim projekcie np. zastosowałem własny uproszczony i lżejszy niż szmarty system szablonów i sprawdza się świetnie.

A jeszcze takie pytanie do tych którzy używają szablonów, bo ja się uczę i chcę się dobrze nauczyć

Jak korzystacie z szablonów to macie folder template w którym macie pliki *.tpl a macie jakiś inny folder w którym przechowujecie pliki które kontrolują zachowanie templatów? Chodzi mi o to że jak macie rejestracja.tpl i np w folderze Controler macie rejestracja.php i w nim robicie wszystko co trzeba zrobić w php i wysyłacie do konkretnego szablonu($tmp->assign('rejestruj','$rejestruj'); $tmp->parse('rejestracja.tpl'))?

masz plik np. jakas_strona.php w katalogu scripts, a w katalogu templates masz plik jakas_strona.tpl, i w przypadku wywołania pliku jakas_strona.php przetwarzasz dane i przekazujesz je do smartów, które wstawiają je w odpowiednie miejsca w pliku jakas_strona.tpl (oczywiście plik nie zostaje zmieniony), a potem zwracają wygenerowany kod html jako wynik działania strony

Jeśli chcesz całkowicie oddzielić kod PHP od szablonów to polecam XSLT po stronie serwera. Smarty dla małych projektów jeszcze ujdzie ale zrobienie czegoś większego na Smarach to porażka.

Od razu ostrzegam że nauczenie się XSLT (wliczając w to xPath) będzie większym wysiłkiem niż nauczenie się Smarty. Osobiście polecam Ci mimo wszystko poznać Smarty bo jest on dość popularny. Potem zająć się XSLT.

piotr94 -> Systemów szablonów nie stosuje się, by oddzielać kod PHP od szablonów... nawet takich, jak Smarty. Zresztą, jak w nim możesz "oddzielać PHP od HTML", kiedy Smarty to składnia PHP ubrana w klamerki?

Fluke -> tak, mniej więcej coś takiego jest, z tą różnicą że to, co trzeba zrobić w PHP nie siedzi w klasach typu "Controller", bo kontrolery w MVC nie są od tego, żeby pompować szablony danymi. Od tego są widoki, jeśli już. Ponadto:



Czy Twój uproszczony system wspomaga tworzenie formularzy? Czy Twój uproszczony system pozwala tworzyć złożone warunki? Czy Twój uproszczony system pozwala na modularyzację szablonów i wielokrotne wykorzystanie tego samego kawałka kodu w różnych miejscach? Z doświadczenia wiem, że w "uproszczonych systemach" często są problemy z tak podstawowymi rzeczami.

Lżejszość to też nie do końca prawda. Taki OPT ma większą funkcjonalność, niż Smarty, więc teoretycznie jest cięższy, a mimo to działa szybciej od niego... W przypadku systemów szablonów większa funkcjonalność wcale nie oznacza, że coś musi działać wolniej; czasami bywa wręcz na odwrót.

Methestel -> mam małe pytanie ad. XSLT: jak rozwiązujesz ten problem, że dane skryptu dla XSLT muszą być podane w formie pliku XML, co wymaga wcześniej zastosowania innego systemu szablonów do wygenerowania tegoż XML-a lub złożonych transformacji? Jak to się ma do szybkości? Na mój gust XSLT powstał w zupełnie innym celu i w formie systemu szablonów dla PHP sprawdza się średnio właśnie z tego powodu, że był projektowany pod kątem zupełnie innej technologii.

Do generowania XML-a używam wyłącznie biblioteki DOM. Nic więcej nie potrzeba.
Jeśli chodzi szybkość to testów niestety nie mam bo i nigdy nie miałem problemów z wydajnością przy używaniu XSLT. Jeśli znajdę czas to postaram jakieś testy zrobić i podzielę się wynikami. Sam jestem ciekaw jak XSLT wypada pod względem szybkości w porównaniu ze Smarty.


Zadaniem XSLT jest przerabianie XML-a na coś innego (np XHTML) tak więc nie mogę się zgodzić że użycie go jako systemu szablonów dla PHP jest sprzeczne z ideą XSLT.

Dla odbiorcy strony praktycznie nie ma różnicy czy strona zrobiona jest na Smarty czy na XSLT.
Dla mnie jako programisty różnica jest ogromna. Sam fakt, że XSLT nie jest połączony z PHP-em przemawia na jego korzyść.