Witam,

Z góry przepraszam za zakłądanie tematu ocierającego się o autoreklamę, ale chciałbym poznać opinię innych programistów na temat prościutkiego systemu szablonów, który jakiś czas temu popełniłem. Nie chodzi mi tyle o znajdowanie błędów (bo raczej ich tam być nie powinno), ile o wrażenia z samego użytkowania: czy łatwo to ogarnąć (ewentualnie będę wdzięczny za wskazówki, co poprawić/dodać w dokumentacji projektu), czy spełnia Wasze oczekiwania co do systemu szablonów. Będę wdzięczny za wszelkie wskazówki dot. funkcji, których ewentualnie brakuje, czy ogólnie rzeczy, które można poprawić.

Projekt można znaleźć na stronie uTemplate.

Z góry dzięki za odpowiedzi.

Uwagi:
1. A co z tablicami? Nie widzę tutaj obsługi tablic (albo nie ma ich opisanych w dokumentacji).
2. Poza tym patrząc na kod źle użyłeś singletona z getInstance - konstruktor ma być prywatny lub protected inaczej ktoś może zrobić new uTemplate = za każdym razem nowy obiekt.
3. Jeśli deklarujesz stałe to zrób to raz, a nie potem w konstruktorze.
4. 1 plik = 1 klasa
5. Trochę za "prosty" jest ten system. Nic nie oferuje oprócz dodatkowego przypisania do zmiennej.

Dzięki za uwagi.
1. W jakim sensie? Bo nie za bardzo kumam, co rozumiesz pod pojęciem obsługi tablic.
2. Zaiste, do poprawienia w wersji 1.3
3. Masz na myśli stworzenie tablicy informacji o doctype? Mogę wyrzucić to z konstruktora i zrobić z tego stałą, ale czy to aż taki mankament?
4. Tak miałem na początku, ale zawsze wolę wrzucić sobie w projekt pojedynczy pliczek niż cały katalog. Kwestia gustu, jak ktoś jest purystą, to może sobie tych kilka linijek klasy widoku przerzucić do oddzielnego pliku. Może kiedyś to rozdzielę, ale w tej chwili to jest niecałe 500 linijek kodu (po odrzuceniu komentarzy), więc tragedii nie ma z trzymaniem wszystkiego w jednym pliku (IMO).
5. No ja wiem, że jest prosty. Właśnie dlatego proszę o sugestie, jak go ulepszyć. Nie mam za bardzo doświadczenia z systemami szablonów poza domyślnym w Zend Frameworku i chciałbym, żeby ktoś bardziej doświadczony wskazał mi trochę drogę dalszego rozwoju uTemplate.

1. Np pobierasz użytkowników z bazy i chcesz ich wyświetlić na liście. Jak to zrobić u Ciebie?
3. Jak stała, to ma być stała

Zakładając, że masz listę użytkowników w zmiennej, to ustawiasz zmienną w szablonie:

[PHP] pobierz, plaintext 
$template->varAdd("users",$users);
[PHP] pobierz, plaintext 

A w samym szablonie jedziesz zwykłym foreachem:

[PHP] pobierz, plaintext 
foreach ($users as $user) {
    echo "<li>{$user}</li>";
}
[PHP] pobierz, plaintext 

Założeniem uTemplate jest korzystać tylko z PHP, bez wprowadzania żadnych sztucznych składni, żadnego metajęzyka, który nie umożliwia korzystania z PHP i wymaga nauczenia się nowej składni. Dzięki temu masz czytelny kod, a przy okazji możesz w samym szablonie użyć sobie funkcji np. ustawiającej znaczniki meta, czy dodającej jakiś javascript w nagłówku strony. Chcesz dopisać coś do titla, to możesz to zrobić bezpośrednio w samym szablonie:

[PHP] pobierz, plaintext 
uTemplate::getInstance()->headTitlePrepend("Bla");
[PHP] pobierz, plaintext 

Osobiście korzystam z tego na mojej stronie firmowej (gdzieś tam jest link na stronie utemplate), jak i na samej stronie uTemplate - dla takich niewielkich stronek sprawdza się świetnie, ale nie wiem np., czy w większych projektach to ma specjalny sens. Bo np. w Zend Frameworku zwykle ustawiasz takie rzeczy w kontrolerze, a widok wypluwa tylko ten fragment HTMLa, który chcesz wstawić w swoje miejsce w layoucie...

głównym powodem powstania systemów szablonów było oddzielenie logiki od prezentacji,
umozliwienie korzystania z php w warstwie prezentacji nie zachęca do utrzymywania takiego podziału...


spaghetti code nigdy nie będzie czytelnym kodem ;P


czyli zaburzasz tutaj podstawową ideę systemu szablonu, wczepiasz do warstwy prezentacji logikę

@rzymek01:
Korzystanie z PHP nie sprawia od razu, że w prezentację wplatasz logikę. Daje taką możliwość, jasne, tu się zgadzam. Ale również zabiera sto innych możliwości, jak chociażby zmiana wielkości liter, formatu liczb, czy użycie gettexta. Jak dla mnie, zmiana "foo" na "FOO" jest czysto prezentacyjna, ale bez PHP musisz sobie z tym radzić w warstwie logiki. Albo inaczej: nie obwiniaj narzędzia za to, że daje możliwość napisania czegoś w sposób, z którego nie korzysta dana aplikacja X (na której opierasz swoje pojęcie "prawidłowej" architektury aplikacji). Jeśli jesteś programistą, a nie byle skrypciarzem, to będziesz wiedział, czego używać, a czego nie używać w widoku.

Spaghetti code? Jeśli fakt korzystania ze znajomej składni PHP do takiego foreacha zamiast jakiegoś metajęzyka od razu przekształca widok w spaghetti, to niech będzie, że masz rację . Nie znam Twojego stylu programowania, czy też tego, z jakim masz na co dzień styczność, więc nie chcę rzucać tu słów na wiatr, ale wydaje mi się, że zapędzasz się tu zdecydowanie zbyt daleko, z krytyki przechodzisz w krytykanctwo/narzekanie. Bo co za różnica, czy napiszesz taką, czy inną składnię pętli? Jedynym kryterium jest tu to, z czym czujesz się swobodniej.

Znaczniki meta itd. - ponownie: to tylko możliwość. Nie musisz tego robić, a jeśli w swojej aplikacji oddzielasz logikę od prezentacji, wręcz nie powinieneś. Ale są aplikacje proste, niekorzystające z MVC, gdzie ktoś może chcieć to zrobić, z powodów, w które nie wnikam. Ma możliwość - czy skorzysta, to jego sprawa. Dla mnie to nie jest zachęcanie do programowania aplikacji "złych", "nieprawidłowych", czy "niezgodnych ze standardami", a po prostu elastyczność. Smarty nie daje takiej opcji, uTemplate daje. Tak, jak z samochodem - jeden ma tempomat, a drugi nie ma. A czy go używasz, czy nie, to już Twoja sprawa i Twój wybór .

Jakby było tak jak piszesz, twórcy Symfony2 nie trudziliby się nad Twigiem tylko zostawili pure php ;-)


możesz napisać dekorator, którego w czytelny i jednolity sposób dla całej aplikacji wywołasz z poziomu szablonu
poza tym, po co od razu php, w css jest text-transform: uppercase; ;-)


kto co woli, dla mnie pomieszanie czystego php z kodem html zawsze będzie spaghetti, niezbyt dobrze go się czyta, ale to najmniejsza wada.

Umożliwienie korzystania z php to naprawdę zły pomysł, dla tego przykładu z pętlą,
po pewnym czasie zamiast jednej konstrukcji pętli w szablonach będzie miał ich 120.
Zmienisz coś w systemie szablonu, to zamiast poprawić w jednm miejscu wywołanie pętli, będziesz musiał przeszukać cały kod i poprawić ręcznie (mnogość konstrukcji)

Nie wiem, w którym miejscu mojego postu widzisz "krytykanctwo"
Pokaż może trochę kodu, w którym wykorzystujesz swój system szablonów,
założę sie, że z możliwością korzystania z php nie trzymasz się ściśle oddzielenia logiki od prezentacji.

Dekorator? Brzytwa Ockhama się kłania: gettext już jest, po kiego grzyba pisać do niego jakiś dekorator? W efekcie masz takie coś: piszesz sobie jakimś metajęzykiem: {gettext Foo}. Do tego musi być parser, który wczyta plik szablonu jako goły tekst, pojedzie po nim jakimś preg_replace, czy jeszcze cięższą magią, żeby ostatecznie i tak dokopać się do wywołania w PHP funkcji gettexta. Ja w tym sensu nie widzę - to tylko niepotrzebne spowalnianie całości, a założę się, że duże projekty by to odczuły. Idąc do osiedlowego sklepiku po browara też "zahaczasz" o drugi koniec miasta?

"Krytykanctwem" dla mnie jest pisanie od razu, że użycie PHP to spaghetti code. Kwestia preferencji. Widzę, że Ty wolisz jakieś tajemne metajęzyki i klamerki, których wiele edytorów nie sparsuje i nie zaoferuje np. podpowiadania składni. Twój wybór, podyktowany pewnie konkretnymi doświadczeniami - nie wnikam, nie neguję. Ja za to jestem przyzwyczajony do Zend Frameworka, gdzie standardowy system szablonów to pliki .phtml, czyli z założenia mieszanka PHP i HTML, a pracując obecnie nad jednym cudzym projektem z jakimś customowym systemem zbliżonym do pierwszego Smarty, od paru miechów przez osiem godzin dziennie rzucam tylko mięchem i marzę o zaczęciu następnego projektu, tym razem opartego na Zendzie lub Drupalu. Dwa odmienne punkty widzenia mamy - i nie dam sobie wmówić, że mój jest "gorszy", bo dla mnie nie jest .

Z mnogością konstrukcji chyba nie kumam Twojej uwagi. Jeśli ja coś zmienię w systemie, np. "ulepszę" składnię jego własnych pętli, to musisz potem ręcznie lecieć po wszystkich widokach i poprawiać. Składnia PHP raczej zmianie nie ulegnie za szybko, foreach na długo pozostanie foreachem. Zakładam, że miałeś coś głębszego na myśli - możesz to trochę rozwinąć?

Własnego kodu z wykorzystaniem uTemplate mam mało - dwie stronki zaledwie. Ich źródeł akurat nie udostępnię, nie mam w zwyczaju udostępniania źródeł konkretnych stron internetowych, ale akurat w tych przypadkach masz rację: moje oddzielenie logiki od prezentacji jest umowne. W poszczególnych widokach ustawiam aktualnie potrzebne "bonusy" do sekcji <head>, głównie tytuł strony, czasem dodatkowy JS, wykorzystywany wyłącznie w danym widoku. W przypadku obu stronek nie było sensu oddzielać wszystkiego "dla zasady", bo to są mikroskopijne stronki (moja firmowa i uTemplate). Nie korzystam tam z UMVC, bo to armata na muchę. Strony nie będą rozbudowywane, a w razie, gdybym chciałtam dodawać dynamiczne treści, przepisałbym je od nowa, korzystając z jakiegoś frameworka (pewnie uMVC, bo własne strony wypada stawiać na własnym oprogramowaniu - jak mój blog na przykład) zamiast "gołego" PHP z samym tylko uTemplate .

pisałeś również o zamianie wielkości znaków czy formatach liczb.
Nawet do gettexta warto napisać nakladkę, po pierwsze oprócz samego gettext być może chcesz wczytać jakąś konfigurację, a po drugie wyraźnie mówisz: pozwalam korzystać z gettext w widoku, i masz pewność, że przykładowo nikt w widoku nie będzie łączyć się z bazą danych


Znam z doświadczenia kilka projektów, w których w widokach stosowane jest php,
nie krytykuję takiego pisania, ale już wspomniałem wyżej, że dla mnie jest to niezbyt czytelne i wprowadza niebezpieczeństwo korzystania w widokach z rzeczy, których nie powinno tam być.

Tutaj kwestia skali. Ty piszesz o projektach typu mała strona WWW. OK. Pewnie piszesz to sam.
W takim układzie to Twoje podwórko, rób co tylko chcesz Ale jak nad projektem pracuje kilka(naście) osób, albo w jego trakcie przewinęło się jeszcze więcej ludzi, którzy już nad nim nie pracują, łatwo o różne kwiatki

Odnosnie wydajności to nie masz racji, bo szablony w systemach jakie znam są kompilowane i cachowane.


Zobacz sobie np. na PHPTAL. Czysty xml/xhtml. Żadnych klamerek, szablon możesz sobie normlanie odpalić w przeglądarce.
A jakiego podpowiadania składni oczekiwałbyś od edytorów? Tych max kilkanaście komend wyświetlania zmiennych/obiektów czy pętli?
Czy może zmiennych, które dodałeś do szablonu. Ale to ostatnie jest trudne do wykonania z racji pewnego rozproszenia w systemach szablonów.
Nawet w Twoim podstawowym systemie szablonów nie będzie podpowiadania składni dla zmiennych przesłanych poprzez varAdd.


Widzisz, osobiście nie jestem nastawiony anty dla takich enginów jak Twój, bo rzeczywistość jest taka, a nie inna i czasem nie ma czasu, nie ma innej możliwości, ale Ty sam się przyznałeś, że jesteś negatywnie nastawiony do enginów z metajęzykami, bo pracujesz na jakimś prehistorycznym systemie


O tej porze już nie myślę, także nie powiem nic mądrego, ale weźmy na przykład iterację po zwykłej tablicy,
możesz mieć:

[PHP] pobierz, plaintext 
1. foreach ($a as $b)
2. foreach ($a as $b => $c)
3. foreach ($a as $b => &$c)
4. for ($i =0; $i < $count($a); ++$i)
5. $count = count($a);
for ($i =0; $i < $count; $i++)
6. jakiś while, do while itd.
[PHP] pobierz, plaintext 

co może powodować problemy z konserwacją kodu i zwiekszeniem ilości WTF/min.
Kod się więcej czasu czyta niż piszę.


OK, mówisz o projektach pisanych w jeden dzień (?), do których się nie wraca (albo rzadko), skąd też szybciej wykonać taki projekt na małych enginach. Jak już pisałem, nie jestem przeciwnikiem takich enginów dla zasady, przy mniejszych projektach można sobie używać, bo czemu nie.
Jednak w miarę rozrostu aplikacji pewnie zaczniesz odczuwać ogólnie mówiąc brak elastyczności enginu.

Nie mam zwyczaju pisać taich długich postów, ale sądzę, że niejako powiedziałem wszystko, co miałem do powiedzenia na ten temat.
Pozdrawiam

PS. nie podoba mi się nazewnictwo funkcji, zwyczajowo najpierw powinien być czasownik (czynność), np.
addVar a nie varAdd, to tak żeby nie było, że się nie czepiam

Dla mnie jednak bardziej czytelne jest:

[HTML] pobierz, plaintext 
{% for user in users if user.active%}
  * {{ user.name|capitalize }}
{% else %}
  * Brak aktywnych użytkowników! *
{% endfor %}
[HTML] pobierz, plaintext 

Jak w czystym PHP byś to zrobił? Mamy tablicę tablic/tablicę obiektów users, chcemy wyświetlić tylko tych, których wartość klucza/własności active === true. Pierwsza litera ich nazwy ma być duża, żeby "grzegorz" zmieniło się w "Grzegorz". Jeśli pętla nie wykona żadnej iteracji - wyświetl tekst o braku użytkowników.

Do tego nie martwię się czy w users jest tablica obiektów czy tablic. Dostęp do nich jest taki sam. Jeśli np user.active jest instancją klasy User, gdzie własność active jest nieosiągalna, system szablonów próbuje ją pobrać metodą getActive(). Elastyczne, nieprawdaż? Do tego wszystko jest cachowane, więc nie interpretujesz za każdym razem tego metajęzyka, ale raz.


Nie, w osiedlowym jest tylko jedno piwo, ja idę na drugi koniec miasta po dwie skrzynki i nie muszę więcej wychodzić z domu przez jakiś czas

o, wreszcie ktoś mysli podobnie do mnie, a już myślałem, że zostalem sam na placu boju :-)

Dobra, chciałem tu odpisać jakąś tyradę, ale chyba za bardzo zbaczamy z tematu. Wyższość jednego sposobu pisania szablonów wolałbym zostawić na jakiś inny moment, zwłaszcza, że nie chcę, żeby z tego wyrósł kolejny głupawy flame .

uTemplate, jak juz pisałem, ma jedno podstawowe założenie: być prostym systemem szablonów, korzystającym z PHP. To się nie zmieni i nie ma sensu dyskutować. Przyjmuję Wasze stanowisko: nie pasuje Wam ten fakt, wolicie systemy z inną filozofią. To była jedna z rzeczy, o które pytałem i za tę odpowiedź Wam dziękuję.