Forum PHP.pl

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 (IMG:style_emoticons/default/wink.gif)

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 (IMG:style_emoticons/default/smile.gif)

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 (IMG:style_emoticons/default/smile.gif) Nie da się, stojąc, podnieść obu nóg do góry i nie rąbnąć na ziemię (IMG:style_emoticons/default/wink.gif)

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.

Ten post edytował Orzeszekk 23.06.2012, 20:25:33

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

Ten post edytował Orzeszekk 24.06.2012, 17:32:58

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.

Ten post edytował Niktoś 24.06.2012, 17:39:49

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.

Ten post edytował !*! 4.07.2016, 14:12:24