PHP templating system changes - discussion

[rapotek]

PHP templating system changes - discussion

[rapotek]

czytelność szablonu zdecydowanie przegrywa bo to tylko komplikuje sytuację - o ile nie robimy głupich rzeczy w widoku to czytelność html + php jest większa niż czytelność html+jakies-tam-spec-template-składnie - w szczególności gdy przecież każdy kto u nas tworzy widoki zna php i jest programistą - to po raz

I tutaj się różnimy. Znam widoki jedne i drugie, te z "klamrami", jeżeli nie zawierają logiki, czyta mi się łatwiej niż wstawki php.

[kojoty]

Wrzucam historię wątku: from: #2354

[kojoty]

[kojoty]

[kojoty]

[kojoty]

[kojoty]

@deg-pl, @rapotek

Hmm... Jeśli dobrze pamiętam, to Ty (@kojoty) wprowadziłeś system template'ów do JS, podczas gdy przecież można używać czystego JS. Sam kiedyś używałem czystego JS do sklejania HTMLa z danymi z API i to był koszmar. Teraz do frontu używam Vue (SFC) i kod jest niesamowicie przejrzysty.

Ale jak pisałem templaty do JS to zupełnie inna bajka niż do PHP ponieważ:

• działają po stronie klienta - to nie obciąża serwera i to jest b. istotna różnica
• pozwalają na wygodne ogarnięcie widoków generowanych dynamicznie - gdy dociągamy jakieś dane z serwera ale już w przeglądarce - np. gdy ktoś coś scroll-uje i pojawiają się kolejne instancje czegoś
• jeśli się używa nowoczesnych frameworków frontendowych jak VUE czy inne angularo-reakty to zupełnie inna bajka - to jest w ogóle nowe podejście gdzie backend robi głównie za API a b. duzo serwisu dzieje się już w przeglądarce

Jest jak najbardziej za templatami w JS i przeciw templatom w PHP (po stronie serwera).

Co do systemu template'ów PHP - ja widzę trzy podstawowe zalety:

• cache'owanie template'ów. To zupełnie coś innego niż wrzucanie zapytań SQL do APCu

No pewnie - cachowanie w rozumieniu smarty to cachowanie widoków - zamiast generować widok mamy już od razu w cacheu gotowy HTML całej strony - ja to kumam - tylko to nie jest wcale takie piękne gdy mamy bardzo dynamiczny serwis i chcemy żeby wyświetlane informacje były zgodne z aktualną rzeczywistością - zapewnienie że to co wyciągamy z cache'a odzwierciedla rzeczywistość to niebanalna sprawa i w praktyce chyba kiepsko się to sprawdza - zwłaszcza gdy widoki są b. często indywidualne - tj. każdy użytkownik może widzieć coś nieco innego na stronie

• wymuszenie poprawności wzorca architektonicznego. System template'ów nie pozwala na wrzucenie kodu PHP, podczas gdy w "obecnym" mamy nawet zapytania do DB. Kiedy zacząłem używać Symfony przeszkadzała mi jego sztywność - brak dostępu do bazy danych w kontrolerze (a nawet w entity). Teraz uważam, że to jedna z największych zalet - jeśli czegoś nie da się łatwo zrobić, prawdopodobnie nie powinieneś tego robić, by nie złamać architektury i logiki. Kod OC jest tak paskudny pod kątem architektury, że mnie za każdym razem szlag trafia gdy trzeba coś zmienić. Pewnie całkiem sporo jest osób, które pomogłyby rozwijać kod, gdyby ten kod jakkolwiek normalnie wyglądał

No pewnie, jest frankensteinem, zlepkiem ulepionym przez lata zmieniających się podejść itd., ale to nie problem systemu templatów ale zasad i ich przestrzegania - to, że zaczniemy używać smarty nie spowoduje, że system się naprawi - zasady - ich zdefiniowanie i przestrzeganie to osobny temat

• dostęp do narzędzi jakie daje system. Można napisać swoje, tylko po co, jeśli są gotowe?

no pewnie - generalnie się zgadzam, ale są tematy tak proste, że nie warto kombinować i można też zrobić samemu, coś co jest proste i idealnie dopasowanie do potrzeb zamiast używać "gotowych" rozwiązań, które przy okazji komplikują życie bo wprowadzają masę dodatkowych zależności - tak by było moim zdaniem np. wprowadzając smarty czy cos podobnego

Generalnie myślę, że OC wcześniej czy później upadnie. I to właśnie dlatego, że nie znajdzie się nikt, kto zrówna kod z ziemią i nie użyje nowoczesnych narzędzi tworząc kod od zera. Ten kod już umarł, a my go tylko czasem łatamy.

Och wiem, OC w ogóle umiera od lat. Niemniej wydaje mi się, że to nie tak jak napisałeś.
Kiedy OC powstawało to ktoś używał "nowoczesnych narzędzi". Później ktoś to przerabiał i znów używał "nowoczesnych narzędzi" (poprzednie w tym czasie już nie były tak nowoczesne). Obawiam się, że to jest proces stałego "unowocześniania" i króliczka nie da się dogonić. Problem w tym, że OC jest robiony amatorsko, często przez amatorów i po godzinach. To jest problemem, a nie to, że nie używamy "nowoczesnych" narzędzi.

"Kod od zera" to pułapka - o ile nie masz budżetu i nie jest to podejście gdzie ktoś siedzi nad tym przez określony czas i to jego główne zadanie - to się nie uda - zaczniesz i nie skończysz - to moim zdaniem najbardziej prawdopodobny scenariusz.

Obecnie serwis obrósł na tyle dużą funkcjonalnością, że ogarnięcie tego "od nowa" to moim zdaniem zabawa naprawdę na rok? pracy na etacie i to nie wiem czy byś skończył przepisywać to wszystko.

Ja dlatego od kilku lat powoli dłubałem przepisywanie tego kawałek po kawałku, ostatnio jakoś straciłem rozpęd, bo zbytnio wciągnęły mnie sprawy zawodowe, ale mam nadzieję, to nie koniec mojej przygody z tym kodem.

[rapotek]

Dorzucę swoje trzy grosze.

Generalnie zgadzam się z @kojoty co do wydajności szablonów w PHP, że jest to niepotrzebny narzut, trudno cacheowalny itp. Tak jest w obecnej sytuacji, gdy mnóstwo logiki związanej z indywidualizacją jest zawarta właśnie w generowaniu widoków HTML. W tym ujęciu robienie cache dla przetworzonych szablonów w najgorszym przypadku może zakończyć się liczbą "instancji" danego widoku zbliżoną do (liczba użytkowników * liczba aktywnych języków).

Natomiast ja od pewnego czasu staram się przenosić maksimum logiki do API + js. Wg mnie optymalnie HTML powinien stanowić tylko wspólny dla wszystkich, statyczny punkt startowy do działań dynamicznych. Przy tym podejściu w ewentualnym szablonie znalazłyby się tylko tłumaczenia, co daje maksimum tyle instancji danego widoku, ile jest aktywnych języków. Z cacheowaniem tego pewnie nawet stary, dobry mustache sobie poradzi.

Właśnie z tłumaczeniami jest największy kłopot, tzn. czy mają być statyczne i dynamiczne, czy np. tylko dynamiczne, jeżeli tak to jak je przekazywać do js itd.? Obecnie mamy ponad 3100 etykiet do tłumaczeń w tablicy. Czy to dużo, czy mało w obecnych czasach - nie wiem.

[andrixnet]

Please let's continue the discussion in english.

IMO if there are changes to be made to the template system used by the site, it should be well documented for all developers. Github Wiki I think fits the purpose well.

I am sure there are pros and cons for several schools of thought.

Without getting into technical details, the template system should be simple, easy to use, easy to insert placeholder via translations, <? ... or should I say independent in syntax and usage from PHP code, all placeholders to be set up in PHP code to be taken by the template subsystem and be replaced properly. Also, uniform across the entire site.

[deg-pl]

Generalnie zgadzam się z @kojoty co do wydajności szablonów w PHP, że jest to niepotrzebny narzut, trudno cacheowalny itp. Tak jest w obecnej sytuacji, gdy mnóstwo logiki związanej z indywidualizacją jest zawarta właśnie w generowaniu widoków HTML. W tym ujęciu robienie cache dla przetworzonych szablonów w najgorszym przypadku może zakończyć się liczbą "instancji" danego widoku zbliżoną do (liczba użytkowników * liczba aktywnych języków).

To nie tak działa.
Template przy pierwszym użyciu jest prekompilowany właśnie do gołego PHP.
Więc narzut czasowy - żaden (poza pierwszym wyświetleniem). Nikt nie mówi o cache'owaniu gotowych widoków, bo to byłaby totalna głupota.

[rapotek]

To nie tak działa. Template przy pierwszym użyciu jest prekompilowany właśnie do gołego PHP. Więc narzut czasowy - żaden (poza pierwszym wyświetleniem). Nikt nie mówi o cache'owaniu gotowych widoków, bo to byłaby totalna głupota.

Sprawdziłem i rzeczywiście tak jest. Akurat cache'owanie gotowych widoków nie uważam za totalną głupotę, gdy jest to kontrolowane, tzn. jest pewność, że po pierwszym użyciu mamy do czynienia wyłącznie ze statycznym kodem. Tak czy inaczej, jeżeli to wygląda w ten sposób, to przy braku zaawansowanej logiki w widoku (a do tego chyba dążymy), nie widzę różnicy w efektywności między szablonem a przeplatanką PHP i HTML w kodzie źródłowym, natomiast czytelność szablonu moim zdaniem wygrywa.

[kojoty]

no nie - zaraz...

czytelność szablonu zdecydowanie przegrywa bo to tylko komplikuje sytuację - o ile nie robimy głupich rzeczy w widoku to czytelność html + php jest większa niż czytelność html+jakies-tam-spec-template-składnie - w szczególności gdy przecież każdy kto u nas tworzy widoki zna php i jest programistą - to po raz

po dwa:
OK co do cachowania - zgadzam się - mój błąd - smarty cachuje wygenerowane templaty a nie html - co nie zmienia sprawy - to tylko sztuczny narzut bo i tak mamy ostatecznie ten sam php do interpretacji przez serwer więc co to dało?

ostatecznie:
przeczytajcie proszę co piszą sami twórcy: https://www.smarty.net/why_use
moim zdaniem w naszym przypadku smarty nie wnosi nic istotnego ponad komplikacje...

za to istotne jest moim zdaniem: definiowanie i trzymanie się zasad tego czym ma być widok jaki tworzymy - tj. minimalizowanie kodu php do warstwy prezentacji

Jak już mówiłem, ale jeszcze podkreślę: systemy templatów do JS są OK i to jest osobna historia

i tak jeszcze na koniec:

Nikt nie mówi o cache'owaniu gotowych widoków, bo to byłaby totalna głupota.

No nie taka totalna, akurat cachowanie już gotowych widoków było conajmniej kiedyś względnie popularne - patrz serwery proxy-cache

[kojoty]

@rapotek
Ja nie wiem - zerknij tutaj https://www.smarty.net/syntax_comparison
Czy to faktycznie coś zmienia na plus jeśli znasz php?
Natomiast wydaje mi się, że bardziej skomplikowane użycia smarty - patrz to:

• https://smarty-php.github.io/smarty/designers/language-combining-modifiers.html
• https://smarty-php.github.io/smarty/designers/language-builtin-functions/language-function-ldelim.html

naprawdę nie ułatwiają tylko utrudniają - po za php trzeba się zapoznać jeszcze z dodatkową skłądnią

niemniej zgadzam się to jest trochę flame-war :) i nie musimy się ostatecznie zgadzać

[deg-pl]

Smarty generalnie to przestarzała kobyła.
Ale w tej dyskusji nie ma to większego znaczenia. Przykłady przytoczone przez @kojoty jak dla mnie - są świetnymi przykładami dlaczego używać systemu template'ów. Są znacznie bardziej czytelne (vide wspomniany wyżej syntax comparision) a do tego mają masę gotowych ułatwiaczy życia - vide modifiers wyżej.
Edit:
Warto też wspomnieć o automatycznym escape'owaniu zmiennych w systemie template'ów.
Przykład z ldelim/rdelim jest nietrafiony. Do wstawek kodu JS najlepiej użyć literal - https://www.smarty.net/docs/en/language.function.literal.tpl
Ponadto od Smarty 3 nawiasy "wąsiaste" są nie intepretowane jeśli są otoczone spacjami. Więc przykład tym bardziej nie trafiony.

[stefopl]

W przypadku popularnych silników szablonów zazwyczaj istnieje jakaś forma integracji Xdebugera i IDE co pozwala na stawianie breakpointów w plikach szablonów.

Nie dorzucę do tej dyskusji nic od siebie, ale mam pytanie. Jak najwydajniej używać tego co już jest w kodzie OC?

W związku z tym, że nie znam kodu OC i dopiero go poznaje naturalne jest, że z przeglądarki najpierw odnajduję interesujący minę fragment w plikach szablonów .tpl.php
W samym pliku szablonu są if-y, foreach-e, wywołania funkcji. A dalej już trudno sprawdzić, czy dany warunek jest spełniony, co zwraca dana funkcja, bo pliki szablonów są w całości wrzucane do stringa, a potem są wykonywane przez eval(). Czy macie wypracowany jakiś patent, integracje z IDE, jakiś dodatkowy parser do tych szablonów? W jaki sposób najwygodniej debugować co dzieje się w tych szablonach?

Edit:
Lokalnie zastąpiłem eval() takim kawałkiem kodu

$viewsDebugPath = __DIR__ . '/../src/ViewsDebug/';
$subDirectory = explode('/', $tplname);

if (! file_exists($viewsDebugPath))
    mkdir($viewsDebugPath, 0777, true);

if (count($subDirectory) >= 2 && ! file_exists($viewsDebugPath . $subDirectory[0]))
    mkdir($viewsDebugPath . $subDirectory[0], 0755, true);

if (count($subDirectory) >= 3 && ! file_exists($viewsDebugPath . $subDirectory[0] . '/' . $subDirectory[1]))
    mkdir($viewsDebugPath . $subDirectory[0] . '/' . $subDirectory[1], 0755, true);

file_put_contents($viewsDebugPath . $tplname . '.php', $sCode);

include $viewsDebugPath . $tplname . '.php';

Dzięki temu w katalogu obok tworzą mi się pliki PHP, które mogę normalnie debugować, ale może jest jakieś lepsze rozwiązanie.

[rapotek]

W przypadku popularnych silników szablonów zazwyczaj istnieje jakaś forma integracji Xdebugera i IDE co pozwala na stawianie breakpointów w plikach szablonów.

Nie dorzucę do tej dyskusji nic od siebie, ale mam pytanie. Jak najwydajniej używać tego co już jest w kodzie OC?

W związku z tym, że nie znam kodu OC i dopiero go poznaje naturalne jest, że z przeglądarki najpierw odnajduję interesujący minę fragment w plikach szablonów .tpl.php W samym pliku szablonu są if-y, foreach-e, wywołania funkcji. A dalej już trudno sprawdzić, czy dany warunek jest spełniony, co zwraca dana funkcja, bo pliki szablonów są w całości wrzucane do stringa, a potem są wykonywane przez eval(). Czy macie wypracowany jakiś patent, integracje z IDE, jakiś dodatkowy parser do tych szablonów? W jaki sposób najwygodniej debugować co dzieje się w tych szablonach?

Edit: Lokalnie zastąpiłem eval() takim kawałkiem kodu

$viewsDebugPath = __DIR__ . '/../src/ViewsDebug/';
$subDirectory = explode('/', $tplname);

if (! file_exists($viewsDebugPath))
    mkdir($viewsDebugPath, 0777, true);

if (count($subDirectory) >= 2 && ! file_exists($viewsDebugPath . $subDirectory[0]))
    mkdir($viewsDebugPath . $subDirectory[0], 0755, true);

if (count($subDirectory) >= 3 && ! file_exists($viewsDebugPath . $subDirectory[0] . '/' . $subDirectory[1]))
    mkdir($viewsDebugPath . $subDirectory[0] . '/' . $subDirectory[1], 0755, true);

file_put_contents($viewsDebugPath . $tplname . '.php', $sCode);

include $viewsDebugPath . $tplname . '.php';

Dzięki temu w katalogu obok tworzą mi się pliki PHP, które mogę normalnie debugować, ale może jest jakieś lepsze rozwiązanie.

Przyznam, że nigdy nie używałem debuggera do kodu PHP, tym bardziej breakpointów. Przy analizie przyczyn błędów bazuję na czytaniu kodu i, ewentualnie, tymczasowym logowaniu w newralgicznych miejscach.
Co do szablonów - mam nadzieję, że chodzi ci o istniejący, przestarzały kod szablonów. Nowy, moim zdaniem, powinien ograniczać się tylko do umieszczania samych tłumaczeń, wtedy debuggowanie w ogóle nie powinno być potrzebne.

[stefopl]

Ja trochę nie mogę sobie wyobrazić nieużywania step debuggera, ale może to kwestia przyzwyczajenia.
Czasami, aby sprawdzić, czy napisany kod na pewno robi to czego oczekiwałem trzeba sprawdzić co zapisało się do zmiennej, co zwróci funkcja gdy zmienię jej parametr albo sprawdzić co siedzi w array(), aby wiedzieć, do czego mogę się odwołać. We wszystkich tych przypadkach musiałbym wypluć interesujące mnie rzeczy do loga lub na ekran tak jak zapewne Ty to robisz. Czyli dopisać fragment kodu, który i tak za chwilę usunę.

Ze step debuggerem wstawiam jednego breakpointa. (Niżej wrzucę screen przedstawiający możliwości.)
I od razu na dole man wypisane wszystkie zmienne globalne z ich wartościami i zmianie lokalne, które są w zasięgu tego kodu.
W tym jednym miejscu zatrzymania w Evaluate mogę wykonywać dowolny kod, czyli odczytywać zmienne, sprawdzać co zwracają różne metody. Przeglądać całą strukturę obiektów lub tablic w czytelny sposób, testować regexy itd.

Mogę też kliknąć, aby automatycznie wszedł do wnętrza metody, którą wykonuje i tam stawiać breakpointy i sprawdzać zmienne lokalne już w tej metodzie.
Przechodzenie krok dalej pozwala na automatyczne otwieranie kolejnych plików, które są po drodze. Podobnie stack trace wystarczy klikać, aby zobaczyć miejsce, z których debuger przyszedł do breakpointa. Normalnie musiałbym odczytać stack trace z logu otworzyć konkretny pliki i w nim wstawiać kolejne wyrzucanie do loga a na koniec trzeba byłoby to wszystko po sobie posprzątać.

Tu właśnie przykład użycia. Tak jak pisałem wcześniej znalazłem małe ułatwienie dla mnie. Zamiast robić eval() na stringu zapisuję stringa do pliku php w katalogu ViewsDebug, który następnie includuje. W takim wygenerowanym pliku już mogę normalnie stawiać breakpointy.

@rapotek Czyli src/ViewsDebug/startPage/startPage.php nie jest dobrym przykładem szablonu?
Mógłbyś podrzucić 2-3 przykłady dobrych szablonów z kodu OC takie jako wzór do naśladowania?

[rapotek]

@rapotek Czyli src/ViewsDebug/startPage/startPage.php nie jest dobrym przykładem szablonu? Mógłbyś podrzucić 2-3 przykłady dobrych szablonów z kodu OC takie jako wzór do naśladowania?

Wszystkie, które nie mają instrukcji warunkowych, pętli itp. Tylko czyste wstawianie wartości.

PS: Z ciekawości ustawiłem sobie XDebuggera pod VSCode. Nie było to proste w mojej konfiguracji (edycja kodu na innym hoście niż jego uruchamianie), ale wreszcie się udało. Może się przydać, dzięki :)