Temat: Nowy system szablonów Twig

Waldemar Jonik:
w założenia dyskwalifikuję webmastera który nie zna podstawowych komend typu if, else, foreach,... chyba , że to webmaster, który tworzy sam kod html,css, js ale on wogólne nie powinien tykać jakiegokolwiek elementu oprogramowania. potem programista nanosi na to logikę np w php. to kwestia organizacji pracy

Czekaj czekaj, czy przypadkiem składnia if, else, elseif nie jest taka sama w PHP i JS?
Foreach w JS trochę jest inny, ale nie odbiega znacznie.

Temat: Nowy system szablonów Twig

Janusz Radkiewicz:

Waldemar Jonik:
nie po to wymyślano szablony żeby upraszczać robotę tylko, żeby do niektórych typów projektów zapewnić separację kodu.

O'rly?
Czekaj, ktoś tu coś pisał o sepracji warstw. Nie pamiętam. Czyżby ja? ;)

separację warstw można wykonać za pomocą samego PHP. chodziło mi o separację zbyt dużych możliwości PHP w stosunku do tego czego potrzebuje szablon napisany PHP. przecież robiąc szablony w php nie dajesz pomiędzy znaczniki html jakiejś skomplikowanej logiki tylko takie same funkcje jakich używasz w innych systemach szablonów.

jeśli już chodzi o separację warstw w takim środowisku pracy tylko XLST zapewni ci prawdziwą separację.

Niemniej korzystam z szablonów, także po to żeby _upraszczać_ sobie robotę,
nawet, gdy to ja robię jednocześnie i za programistę i za webmastera.

no zgadzam się , szablony napisane w PHP też upraszczają robotę :)

Mam kilka innych kryteriów, które stosując oceniam, czy użycie szablonów jest _wskazane_ czy zbędne.

nadal mylisz pojęcia - system szablonów może być zrobiony w czystym PHP.
szablony nie oznaczają używania odmiennej składni języka.

to jest zupełne pomylenie pojęcia szablonu.

same dyskusje nad wyborem czy używać szablonów w czystym php czy osobnych znaczników toczą się od bardzo dawna. wszystkie poważne frameworki pozwalają używać także szablonów w czystym php tak samo jak każdego innego systemu szablonowego. zwykle to przyzwyczajenia albo organizacja pracy decydują o tym
czy używać systemu szablonów opartym na php, czy kompilowanych czy tych opartych na XML/XSLT

dla zainteresowanych małe zestawienie:

http://webification.com/best-php-template-engines

są tu systemy szablonów w czystym php i także te kompilowane

Temat: Nowy system szablonów Twig

Michał Wachowski:

Czekaj czekaj, czy przypadkiem składnia if, else, elseif nie jest taka sama w PHP i JS?
Foreach w JS trochę jest inny, ale nie odbiega znacznie.

o to mi właśnie chodzi, jeśli ktoś zna te komendy to chyba poradzi sobie z szablonami w czystym PHP np z takim Savant

Temat: Nowy system szablonów Twig

Waldemar Jonik:

obecnie ja jestem właścicielem firmy i ja zatrudniam ludzi w tym webmasterów, czasami także osoby na zlecenie ale tylko takich którzy znają php :)

Zanotujmy: "tylko takich, którzy znają PHP" :)

nie wiem skąd ty znasz takich webmasterów, poznanie podstaw php jest tak samo trudne jak poznanie podstaw systemu szablonów.

Znam stąd, iż nie skreślam webmasterów, którzy nie znają PHP.
Ostatnio pracowałem z jednym Mołdawianinem, podstawy szablonów przyswoił błyskawicznie, o resztę potrafił dopytać. Programować nie potrafi.

w założenia dyskwalifikuję webmastera który nie zna podstawowych komend typu if, else, foreach,... chyba , że to webmaster, który tworzy sam kod html,css, js ale on wogólne nie powinien tykać jakiegokolwiek elementu oprogramowania. potem programista nanosi na to logikę np w php. to kwestia organizacji pracy

Aha... potem. Myślenie życzeniowe. Bo po tym "potem" może zaistnieć konieczność kompletnego wymienienia layoutu.
Czyli co, robota od nowa?

Szablony dają mi też inną przewagę.
Programista robi zgrzebne makra "produkt", "news" etc. i zostawia w osobnym pliku. Sam z nich korzysta, zapinając w iteratory itp. Ba, cała strona może być jednym makrem (zawierającym inne makra, a te jeszcze inne).
W tym wypadku webmaster nie ma do czynienia z żadnyi warunkami, generowanie serii itp. ma tylko ładnie nazwane parametry, projektuje wygląd konkrentych pudełek, robi "skina" i jeszcze sam decyduje, w którym miejscu co się wyświetli. Tyle, że taki zabieg stosuję sporadycznie, niemniej jest możliwy i przy sporym projekcie właśnie tak bym to poprowadził.
Abstrakcyjna formatka kontrolera dla programistów, i wielopoziomowe "repozytorium wyglądu" przy którym majsterkują "stylilści".
I w każdej chwili mogę "jednym pstryczkiem" zmienić cały wygląd na coś w rodzaju "var_dumpów", by sprawdzić poprawność samej logiki.
Na słowo musisz uwierzyć, że ów system makr, to o rzędy wielkości więcej niż CSS ;)

...i szukaj potem po historii wersji, kto i kiedy coś popsuł...

tego nie trzeba specjanie szukać. przecież kod i tak musi przejść testy. ktoś to musi zweryfikować

Zrobiwszy testy _logiki_ nie chcę znów szukać "winnego", który np. nadgorliwie zjadł średnik po for(...); - ja wiem, że on w _tym_konkretnym_przypadku_ ma tam być, lepiej, żeby go webmaster nie mógł "poprawiać" domniemując, że po for(...) coś się powinno wykonywać ;)

czy to szablony php czy inne to i tak masz zupę tagów tylko z innymi znacznikami. obojętnie jakich znaczków użyjesz do tworzenia np instrukcji warunkowych, iteracji itp to i tak jesteś na tym samym poziomie trudności.

Po pierwsze, mam tylko te, kóre są pożądane z punktu widzenia prezentacji.
Po drugie, mam dodatkowe, których implementacja w PHP nie jest oczywista.
Po trzecie w końcu, znaczniki te są niezależne od platformy aplikacji, gdy logikę przepiszę na inny język, szablony zostaną te same (sam silnik potrafię napisać w kilku językach, w ostateczności pobrać same dane do PHP, w którym _nikt_ już nie musi _nic_ pisać, ani go znać).

nie pozwoli ci to wyjść na jakiś wyższy poziom programowania.

Ja bardzo dobrze się czuję na swoim poziomie i daleki jestem od tego, by oceniać, czy masz podstawy patrzeć nań z góry. Przynajmniej publicznie ;p
Ale może masz ochotę na jakiś "test kompetencyjny" (nie związany z szablonami), by sobie (i mnie) "skilla" okreslić? Dziecinada, ale nawet lubię quizy ;)

widzę, że ciągle nie rozumiesz, że kod php może sam w sobie być systemem szablonów

Zatem niedowidzący jakiś jesteś. Świetnie rozumiem, że "może być", co nie oznacza, że uważam to za "najfajniejsze" rozwiązanie.

od wielu lat pracuję nad projektami aplikacji także takimi dla dużych korporacyjnych firm

oh! ah! Że niby teraz moja kolej na przedstawienie portofolio, referencji i kluczowych klientów? A możemy bez tego chełpienia się (nie, żebym nie miał się czym pochwalić)?
Nadto "a mój dziadek dożył 97 lat i do śmierci palił szlugi, a Churchill cygara, ergo brednie o szkodliwości palenia można między bajki włożyć" to też kiepskie argumenty, nawet gdy palący dziadek nie był fikcyjny.

Wiesz, nie rozumiem tej krucjaty.
Paru gości rozmawia o szablonowaniu (nie o korzyściach z niego płynących, te widocznie znają). A odzywają się osoby, które "nie czują konieczności, nie rozumieją, nie widzą sensu" etc. niektórzy siląc się na "autorytatywny" ton.

Ja nie widzę potrzeby korzystania z wielu innych bibliotek, ale nie włażę w tematy ich dotyczące, by tam o tym opowiedzieć. Ale ja to truskawki cukrem...

Temat: Nowy system szablonów Twig

Waldemar Jonik:

Janusz Radkiewicz:

Waldemar Jonik:
nie po to wymyślano szablony żeby upraszczać robotę tylko, żeby do niektórych typów projektów zapewnić separację kodu.

O'rly?
Czekaj, ktoś tu coś pisał o sepracji warstw. Nie pamiętam. Czyżby ja? ;)

separację warstw można wykonać za pomocą samego PHP.

A gwoździe wbijać żelazkiem.
W tym za to miejscu chodziło o to, że usiłujesz pouczać mnie, _po_co_ używa się szablonów (separacja) o czym jednak wiem (i wcześniej pisałem), a _po_co_ nie, z czym akurat się nie zgodzę, gdyż dobrze przemyślane szablony _upraszczają_ robotę.
Choćby przez czytelniejsze kolorowanie składni bez mieszania języka prezentacyjnego (kto powidział, że to ma być np. XHTML?) z PHP (czy innym).
Pozwalają także na łatwą migrację aplikacji na inny język.
To ma być _wygodny_ interfejs.

chodziło mi o separację zbyt dużych możliwości PHP w stosunku do tego czego potrzebuje szablon napisany PHP. przecież robiąc szablony w php nie dajesz pomiędzy znaczniki html jakiejś skomplikowanej logiki tylko takie same funkcje jakich używasz w innych systemach szablonów.

Szablony pisane wprost w PHP stają prędzej czy poźniej przed koniecznością użycia jakieś funkcji, klasy etc. Może (choć nie musi) zacząc się jazda z ' oraz ", specyficznym dla PHP scopingiem (odcięcie od globalnych, gdy większość języków tylko przysłania kolidujące zmienne) itp. itd.
Sensownie zaprojektowane szablony nie mają tych wad.
Nie wszystkie są sensowne, tej tezy absolutnie nie bronię.

jeśli już chodzi o separację warstw w takim środowisku pracy tylko XLST zapewni ci prawdziwą separację.

Uważaj na nisko przelatujące kwantyfikatory, tezy oparte na "tylko, zawsze, nigdy" itp. zwykle łatwo się obala. :)

Niemniej korzystam z szablonów, także po to żeby _upraszczać_ sobie robotę,
nawet, gdy to ja robię jednocześnie i za programistę i za webmastera.

no zgadzam się , szablony napisane w PHP też upraszczają robotę :)

Też. I umiem je pisać. A jednak używam innych. Zatem:
- może jednak nie umiem pisać pehapowych "oprawek"?
- może jestem masochistą?
- może bezmyślnie uległem modzie i uważam, że sama technologia daje mi +20 do splendoru a epatowanie technobełkotem pozwala utwierdzić potencjalnego klienta, że znam się na robocie?
- a może po prostu widzę pewne zalety, których Ty nie dostrzegasz (i może nie są dla Ciebie istotne w tym, co _Ty_ robisz)?

Mam kilka innych kryteriów, które stosując oceniam, czy użycie szablonów jest _wskazane_ czy zbędne.

nadal mylisz pojęcia - system szablonów może być zrobiony w czystym PHP.

Sluchaj, daruj sobie ten mentorski ton, bo zaczynasz być nieprzyjemnie irytujący.
To, że Ty nie rozumiesz, że pisząc "szablonowanie", piszę o tym, o czym wskazuje temat tej dyskusji (dedykowanych systemów szablonowania, nie o użyciu czystego PHP jako warstwy szablonującej) nie uprawnia Cię do oceniania mej zdolności pojmowania.

szablony nie oznaczają używania odmiennej składni języka.

Szablony cechują się zwykle _własną_ składnią, najlepiej, gdy _niezależną_ od języka generującego dane. Tak jak html ma swoje kanony, ma je też postsrcipt, szablony powinny dopuszczać rozmaite serie (iteracje, rekurencje), kilka prostych warunków, makra jakoweś.
Struktura programu odbiega od struktury dokumentu, a PHP wcale nie jest "zotym środkiem" który świetnie sprawdzi się w obu zastosowaniach.
Może się sprawdzać, podobnie, jak niemal dowolny język progamowania może "generować dokument", ale nie nadaje się do tego idealnie.

to jest zupełne pomylenie pojęcia szablonu.

no co Ty nie powiesz?
A zakładasz w ogóle, że może to Ty masz inne spojrzenie na temat?
Czy jednak Twoje pojęcie jest jedynie słuszne?

same dyskusje nad wyborem czy używać szablonów w czystym php czy osobnych znaczników toczą się od bardzo dawna.

No patrz, "idioci" nie wyginęli. Ale Ty będziesz ich dzielnie edukował. W końcu się poznają na prawdziwym geniuszu i przestaną dyskutować, przyjmując Twój nieomylny punkt widzenia.

wszystkie poważne frameworki pozwalają używać także szablonów w czystym php tak samo jak każdego innego systemu szablonowego.

Skandal, powinni tego zabronić. Wyłącznie czyste PHP!

zwykle to przyzwyczajenia albo organizacja pracy decydują o tym
czy używać systemu szablonów opartym na php, czy kompilowanych czy tych opartych na XML/XSLT

czy jeszcze innych...

dla zainteresowanych małe zestawienie:

http://webification.com/best-php-template-engines

są tu systemy szablonów w czystym php i także te kompilowane

I zapewniam Cię, że jest jeszcze wiele nieujętych :)

Temat: Nowy system szablonów Twig

Ta dyskusja jest bez sensu.

Ok, trywialny przykład. Ręka w górę, dla kogo:

<?php echo $zmienna; ?>

jest lepsze/czytelniejsze/łatwiejsze do modyfikacji, niż

{$zmienna}

albo

{{ zmienna }}

Przecież to nawet matematycznie da się udowodnić, że lepszym wyborem są opcje 2 i 3. Jak można w ogóle z tym dyskutować?

// EDIT: o! i zapomniałem "echo" ;]Łukasz K. edytował(a) ten post dnia 18.05.11 o godzinie 17:53

Temat: Nowy system szablonów Twig

Dariusz Półtorak:

Są na to 3 sposoby. Pierwszy to konfiguracja php.ini. Ze względu na to że Blitz jest nastawiony na jak największą wydajność, zasięg zmiennych ogranicza się do bloku w którym jesteśmy. Ale mamy do dyspozycji opcję:

blitz.scope_lookup_limit

która pozwala nam na zarządzanie widocznością. Np 3 sprawi że jeżeli nie znajdzie zmiennej w bieżącej iteracji to poszuka maksymalnie do 3 rodziców wstecz.

No właśnie to raczej nie zadziała, bo masz strukturę hierarchiczną obiektów tego samego typu z takimi samymi polami, więc lookup zadziała od razu na tym samym poziomie.

Druga możliwość tu uczynienie zmiennej rodzica globalną.

Było coś o nierobieniu z HTMLowca programisty :).

Jeżeli wymyślimy coś tak chorego że nie da rady tego zrealizować Blitzem, zawsze możemy sterować iteracją bloku z poziomu PHP.

Temat: Nowy system szablonów Twig

Dariusz Półtorak:
Wiecie, krytykowanie systemów szablonów przypomina mi troszkę dywagacje właśnie na temat programowania obiektowego.
Jedni twierdzą że to kupa, inni że diament. Obaj mają rację w różnych względach i sytuacjach ale prawda jest taka że kto ma diament ten po kupę już raczej nie sięgnie.

Problem jest jak trzeba rzeźbić w tym drugim.
Wszystko jest kul do momentu gdy chcesz zrobić coś, czego autor nie przewidział.

Nie mniej jednak właścicielowi kupy czasami trudno wytłumaczyć co to diament. To jak z gruszką. Jest słodka i ma kształt. Niech tu ktoś zdefiniuje kształt gruszki.

Bryła zawarta w otoczce wypukłej 2 niezawierających się sfer o różnych promieniach mających jeden punkt wspólny razem z tą otoczką.
Ostatecznie można zamiast otoczki użyć paraboli czy czegoś.

Temat: Nowy system szablonów Twig

Łukasz K.:
Ta dyskusja jest bez sensu.

Ok, trywialny przykład. Ręka w górę, dla kogo:

<?php echo $zmienna; ?>

jest lepsze/czytelniejsze/łatwiejsze do modyfikacji, niż

{$zmienna}

albo

{{ zmienna }}

<?=$zmienna?>

Temat: Nowy system szablonów Twig

Jakub L.:

Łukasz K.:
Ta dyskusja jest bez sensu.

Ok, trywialny przykład. Ręka w górę, dla kogo:

<?php echo $zmienna; ?>

jest lepsze/czytelniejsze/łatwiejsze do modyfikacji, niż

{$zmienna}

albo

{{ zmienna }}

<?=$zmienna?>

Czasem to PHP odcina się od tego zapisu na rzecz <?php ?> ? Poza tym

<?=$zmienna?>

{{ zmienna }}

Nie żartuj sobie ;)

Temat: Nowy system szablonów Twig

Jakub L.:

No właśnie to raczej nie zadziała, bo masz strukturę hierarchiczną obiektów tego samego typu z takimi samymi polami, więc lookup zadziała od razu na tym samym poziomie.

powiedzmy, że moja zabawka nie ma z tym problemu, odwołuje się do bieżącego scopingu i nieprzesłoniętych zmiennych "ponad", ale ma także dostęp do wyłącznie siebie, swego klucza/indeksu, a także "parenta". MOżna dostać ojca, dziadka etc.

Druga możliwość tu uczynienie zmiennej rodzica globalną.

Można też skorzystać z jakiegoś "helpera", który zapisze zmienną przed, a potem wewnątrz iteracji ją odczyta.

Było coś o nierobieniu z HTMLowca programisty :).

Dlatego u mnie funkcje (dowolne, jakie tam programista na potrzeby webmajstra wymyśli) mają zadanie głownie prezentacyjne i używa sie ich jak znanych hateemelowcowi tagów - jakoś nie panikują. Zwykle są to jakieś wspomagające formatery.

Jeżeli wymyślimy coś tak chorego że nie da rady tego zrealizować Blitzem, zawsze możemy sterować iteracją bloku z poziomu PHP.

Ale jeżeli sposób prezentacji nakazuje wyświetlać infotmacje o przodkach, to nie jest wielkim nadużyciem takie przygotowanie danych, by określone tablice w dodatkowym kluczu przechowywały referencję do elementu nadrzędnego. I po kłopocie ;)

Wyświetlenie tego "gołym" PHP też wymaga pewnej nadmiarowości.

Temat: Nowy system szablonów Twig

Janusz Radkiewicz:

Zanotujmy: "tylko takich, którzy znają PHP" :)

w moim przypadku tak bo na php jest najwięcej klientów i przynosi to najlepsze dochody. a jeśli programujemy w czymś innym np takim python to i tak okazuje się, że trzeba użyć innego typu szablonów - np TAL

Ostatnio pracowałem z jednym Mołdawianinem, podstawy szablonów przyswoił błyskawicznie, o resztę potrafił dopytać. Programować nie potrafi.

to jak wykonuje w layout elementy np javascript?

Po trzecie w końcu, znaczniki te są niezależne od platformy aplikacji, gdy logikę przepiszę na inny język, szablony zostaną te same (sam silnik potrafię napisać w kilku językach, w ostateczności pobrać same dane do PHP, w którym _nikt_ już nie musi _nic_ pisać, ani go znać).

ale po co przepisywać na inny język? a nawet jeśli to przypuszczam, żemożna spokojnie napisać sobie narzędzie które 99% kodu takich szablonów przekonwertuje na inny typ szablonów

Ale może masz ochotę na jakiś "test kompetencyjny" (nie związany z szablonami), by sobie (i mnie) "skilla" okreslić? Dziecinada, ale nawet lubię quizy ;)

nie, z tego się wyrasta i niektórych to nie bawi bo nie ma to zupełnie sensu.
nie wiem czemu ciągle coś osobistego do mnie kierujesz. mi tylko zależało na porównaniu jednych szablonów do innych.

Zatem niedowidzący jakiś jesteś. Świetnie rozumiem, że "może być", co nie oznacza, że uważam to za "najfajniejsze" rozwiązanie.

a ja uważam inaczej i mam do tego prawo skoro szablony w php nie są m mojej pracy jakimkolwiek wąskim gardłem.

Wiesz, nie rozumiem tej krucjaty.
Paru gości rozmawia o szablonowaniu (nie o korzyściach z niego płynących, te widocznie znają). A odzywają się osoby, które "nie czują konieczności, nie rozumieją, nie widzą sensu" etc. niektórzy siląc się na "autorytatywny" ton.

czyste php to też jest szablonowanie a my po prostu chcieliśmy porównać jedne szablony z innymi. to jak sprawdza się szablonowanie w php w porównaniu z szablonowaniem opartym na osobnym zestawie znaczników - to narzędzia do wykonywania tych samych czynności więc można je porównać bo jak inaczej opisać takiego Twig bez porównywania go z czymś innym?

ja nie dyskwalifikuje jakiegokolwiek sposobu szablonowania (miałem i mam okazje czasami korzystać) jeśli jest on skuteczny i sprawdza się w danych rozwiązaniach (a każdy się gdzieś sprawdza skoro tyle ich jest i ciągle powstają nowe) - w twoich wypowiedziach za to widzę całkowite negowanie szablonów php (tak, to są szablony) a nawet wszystkich innych poza tymi których sam używasz.

Temat: Nowy system szablonów Twig

Waldemar Jonik:

Janusz Radkiewicz:
Zanotujmy: "tylko takich, którzy znają PHP" :)

w moim przypadku tak bo na php jest najwięcej klientów i przynosi to najlepsze dochody. a jeśli programujemy w czymś innym np takim python to i tak okazuje się, że trzeba użyć innego typu szablonów - np TAL

czegoś gorszego niż "gołe PHP"? No wiesz?!

Ostatnio pracowałem z jednym Mołdawianinem, podstawy szablonów przyswoił błyskawicznie, o resztę potrafił dopytać. Programować nie potrafi.

to jak wykonuje w layout elementy np javascript?

Zwykle tragicznie, kopiując nieporadnie jakieś gotowce, ale został tego oduczony. Na szczęście potrafi wysłać maila i opisać/narysować to, czego oczekuje. Walidację dowolnych pól formularza dowolnym zestawem przygotowanych funkcji (z opcjonalnymi parametrami) dostał, sposób walidacji i komunikat błędu (po którym dodatkowo w pierwszym błędnym polu ustawia się focus) obsługuje atrybutami. W sumie kilka linijek JS na walidator, plus zestaw prostych funkcji, zaś obsługa w stylu:

<input .....

 data-valid="nospace, size 3 6"

 data-alert="pole powinno mieć od 3 do 6 znaków i nie zawierać spacji"

>

nie przerasta typowego hateemelowca i trudno nazwać to programowaniem.
Pewne elementy, np. interaktywne robi się jako makra, naprawdę nie jest to większym problemem. Sytuacje, w których hateemolowiec radośnie sieje JS po HTML w "przypadkowych miejscach" wcale nie muszą mieć miejsca.

a nawet jeśli to przypuszczam, żemożna spokojnie napisać sobie narzędzie które 99% kodu takich szablonów przekonwertuje na inny typ szablonów

Ciężko konwertować funkcjonalność, której silnik docelowy nie obsługuje.
No i bardzo jestem ciekaw, jak sobie taki konwerter poradzi z konwersją szablonowania "gołym PHP" takim, co np. jakieś swoje klasy do elementów rekurencyjnych ma.

nie, z tego się wyrasta

ludzie, którzy wyrastają z zabawy, są nudziarzami ;)

i niektórych to nie bawi bo nie ma to zupełnie sensu.

Nie no, jasne, lepiej "sprawiać wrażenie bardziej doświadczonego" i nadawać mentorskim tonem w stylu "co ty wiesz o programowaniu" i "dorośniesz, zobaczysz". ROTFL.

Umówmy się może, że jak nie chcesz się sprawdzić, to nie opowiadacz, jaki jesteś świetny, tylko pozwalasz sobie wyrobić zdanie o sobie ma podstawie swych wypowiedzi. Z tym sprawdzaniem to miał być w sumie żart, ale widzę, że nadal starasz się stawiać "ponad". I to właśnie jest _niedorosłe_.

nie wiem czemu ciągle coś osobistego do mnie kierujesz.

a) całkiem bezpodstawnie
b) w przeciwieństwie do Ciebie, czytam, co napisałeś i reaguję na "traktowanie z góry"?

mi tylko zależało na porównaniu jednych szablonów do innych.

Super, rozumiem, że już nie będę miał wspominanego odczucia ;)

Zatem niedowidzący jakiś jesteś. Świetnie rozumiem, że "może być", co nie oznacza, że uważam to za "najfajniejsze" rozwiązanie.

a ja uważam inaczej i mam do tego prawo skoro szablony w php nie są m mojej pracy jakimkolwiek wąskim gardłem.

"w mojej pracy" - to dupocentryczne postrzeganie świata ma pewne wady, otóż nie każdy jest w "twojej pracy/sytuacji".

ja nie dyskwalifikuje jakiegokolwiek sposobu szablonowania (miałem i mam okazje czasami korzystać) jeśli jest on skuteczny i sprawdza się w danych rozwiązaniach (a każdy się gdzieś sprawdza skoro tyle ich jest i ciągle powstają nowe) - w twoich wypowiedziach za to widzę całkowite negowanie szablonów php (tak, to są szablony) a nawet wszystkich innych poza tymi których sam używasz.

Wskaż mi proszę owo "całkowite negowanie wszystkiego" z naciskiem na całkowite i wszystkiego. Ostrzegałem przed nisko przelatującymi kwantyfikatorami?Janusz Radkiewicz edytował(a) ten post dnia 19.05.11 o godzinie 10:21

Temat: Nowy system szablonów Twig

Jakub L.:

Dariusz Półtorak:

Są na to 3 sposoby. Pierwszy to konfiguracja php.ini. Ze względu na to że Blitz jest nastawiony na jak największą wydajność, zasięg zmiennych ogranicza się do bloku w którym jesteśmy. Ale mamy do dyspozycji opcję:

blitz.scope_lookup_limit

która pozwala nam na zarządzanie widocznością. Np 3 sprawi że jeżeli nie znajdzie zmiennej w bieżącej iteracji to poszuka maksymalnie do 3 rodziców wstecz.

No właśnie to raczej nie zadziała, bo masz strukturę hierarchiczną obiektów tego samego typu z takimi samymi polami, więc lookup zadziała od razu na tym samym poziomie.

Dlatego mówię że jest więcej jak jeden sposób. Wszystko zależne od sytuacji.

Druga możliwość tu uczynienie zmiennej rodzica globalną.

Było coś o nierobieniu z HTMLowca programisty :).

Od strony HTMLowca wygląda to tak samo. Ot ma zmienną. Ale też nie jest to wygodny sposób jeżeli mamy w miarę złożone dane.

Jeżeli wymyślimy coś tak chorego że nie da rady tego zrealizować Blitzem, zawsze możemy sterować iteracją bloku z poziomu PHP.

No widzę że tego ostatniego nie skomentowałeś. W przypadkach gdy już na prawdę nie możesz sobie poradzić możliwością szablonów, przerzucasz kontrolę do PHP w prosty sposób:

$Blitz = new Blitz('lista.tpl');



$rodzic = 'nikt';

foreach($twojaTablica as $k => &$osoba) {

    $osoba['rodzic'] = $rodzic['imie'];

    $Blitz->block('/osoby', $osoba);

    $rodzic = $osoba;

}



$Blitz->display();

Co zrobiłeś ? Zostawiłeś logikę w szablonie. Iterację bloku zrobiłeś ręcznie dorzucając pod 'rodzic' poprzedni element tablicy (oczywiście to tylko głupi przykład ukazujący o co mi chodzi). A jak to wygląda od strony webmastera który przygotowuje szablon ?

{{ BEGIN osoby }}

    Jestem {{ $imie }} a przede mną był {{ $rodzic }}

{{ END }}

I o ile programista musiał sięgnąć po ręczną iterację (choć można by się zastanowić czy nie zrobić tego inaczej no ale jak mówiłem - z Blitza ostatnio korzystałem niecały rok temu albo może pół) o tyle webmaster ma już prościej i nie zaprząta sobie głowy takimi rzeczami jak poprzedni element czy też element który jest poziom albo 5 wyżej.

Oczywiście to banalny przykład i nie pokazuje tu raczej nic czego nie zrobisz w innych szablonach ale teraz sobie wyobraź 5 list na stronie które są wyświetlane osobno ale są też zależne od siebie. Np iterujesz jedną a w momencie jak trafisz na coś specjalnego, iterujesz drugą itp.
Pełna kontrola.

Kolejna rzecz jaką uwielbiam to możliwość zrzucenia struktury szablonu. Dzięki temu można sobie np napisać narzędzie które zrobi kontrolę szablonu zrobionego przez webmastera. Tworzymy szablon minimalny (czyli taki który zawiera tylko to co niezbędne) a następnie zrzucamy jego strukturę i strukturę szablonu webmastera.
Tak uzyskane tablice porównujemy. Fajny bajer wg mnie.Dariusz Półtorak edytował(a) ten post dnia 19.05.11 o godzinie 10:55

Temat: Nowy system szablonów Twig

Janusz Radkiewicz:

Waldemar Jonik:

Janusz Radkiewicz:
Zanotujmy: "tylko takich, którzy znają PHP" :)

w moim przypadku tak bo na php jest najwięcej klientów i przynosi to najlepsze dochody. a jeśli programujemy w czymś innym np takim python to i tak okazuje się, że trzeba użyć innego typu szablonów - np TAL

czegoś gorszego niż "gołe PHP"? No wiesz?!

kolejny raz mówię- używa się tego co jest w danej chwili wygodne i opłacalne, nie musi być to koniecznie np ulubiony system szablonowania.

jeśli używa się ZOPE to TAL jest to standard i nie ma sensu podmienia na inny typ szablonowania. to tylko kwestia kosztu takiej pracy - gdy pracujesz nad czymś co jest gotowe to stosujesz to co masz bo tak jest taniej/wygodniej.
ale nawet w tym ZOPE np przy budowie wielopoziomych drzew menu często szybciej wygodniej jest coś zrobić w czystym Python niż bawić się w szablony.

Umówmy się może, że jak nie chcesz się sprawdzić, to nie opowiadacz, jaki jesteś świetny,

ani razu nie wspominałem, że jestem świetny i nie muszę się z tobą w niczym umawiać i czegokolwiek udowadniać, zwłaszcza, że zajmuje się więcej organizacją pracy w zespołach programistów niż samym programowaniem. opisuje tylko to , co sprawdza się w długo rozwijanych projektach i realizacjach różnego typu aplikacji, nie tylko w mojej firmie.

"w mojej pracy" - to dupocentryczne postrzeganie świata ma pewne wady, otóż nie każdy jest w "twojej pracy/sytuacji".

i tego nie neguje , opieram się tylko na konkretnym doświadczeniu. nie wiem czemu tak ci się nie podoba, że wspomniałem o tym, że mam jakieś doświadczenie i po używaniu różnych typów szablonów wolę czysty PHP i wiele osób też tak wybiera ale nie są przez to ani gorsi ani lepsi.

Ostrzegałem przed nisko

przelatującymi kwantyfikatorami?

nie wiem o co ci chodzi, w normalnej rozmowie nigdy bym nie pomyślał, że ktoś używa kwantyfikatorów i nie rozbijał bym kogoś wypowiedzi na czynniki proste bo nie dość , że gubisz sens wypowiedzi to traktujesz rozmówcę zero-jedynkowo - my tu rozmawiamy , nie programujemy i każdę słowo jest płynne :)

Temat: Nowy system szablonów Twig

czegoś gorszego niż "gołe PHP"? No wiesz?!

kolejny raz mówię- używa się tego co jest w danej chwili wygodne i opłacalne

W tej chwili i na przyszłość, jeśli liczysz się z konserwacją aplikacji.
Ale mniej więcej zgoda.

Dlatego też uważam opinie w stylu "na co to komu, skoro jest PHP!" za prezentujące wąski typ widzenia. A skoro powinny brzmieć "na co to _MI_, _JA_ nie potrzebuję", to nie jest to właściwe miejsce do ich głoszenia.
Ja np. nie wcinam się w dyskusję o rowerach górskich z tekstem "a na co to komu, JA mieszkam w mieście, TU jest płasko i wszędzie MAM asfalt, po co MI tyle przełożeń, szerokie opony, amortyzacja, to durnota, to waży, to kosztuje, to zwiększa opory".
I wcale nie piszę, że Ty to robisz, celowo przerysowałem pewien _typ_ wypowiedzi, jakie padały.

ani razu nie wspominałem, że jestem świetny

nie wspominałeś, tylko poleciałeś "wyższością", ale mieliśmy dać już sobie z tym spokój?

i nie muszę się z tobą w niczym umawiać

Prawdziwie wolny człowiek! Nie musi.

[ciach]

Ostrzegałem przed nisko

przelatującymi kwantyfikatorami?

nie wiem o co ci chodzi

i w sumie nie musisz, podsumowanie już było, w adpersony nie chcę się bawić ;)