Coraz częściej spotykam się z kodem pisanym na szybko
przez ludzi mających nikłe pojęcie o swoim podstawowym narzędziu pracy - języku PHP. Kawałki kodu wyglądają tak:
while($row = mysql_fetch_array($result))
{
print "<tr><td>" . $row['imie'] .
"</td><td>" . $row['nazwisko'] .
"</td><td>" . date("d.m.Y", $row['data_urodzenia']) .
"</td></tr>\n";
}
Kod paskudny i na ogół wyświetlanie wyników zajmuje przynajmniej 3/4 pliku, który odpowiada za ich pobieranie z bazy. Znacznie wygodniej byłoby oddzielić widok od kontrolera i pozwolić temu pierwszemu troszczyć się o formatowanie danych (date(...);), a temu drugiemu zająć się tylko wydobywaniem niezbędnych danych.
Tutaj pojawiają się szablony. Równie kiepskim pomysłem, jak wypluwanie kodu HTML bezpośrednio przez kontroler, jest pisanie własnego silnika szablonowego. Znacznie lepiej stosować powszechnie uznane narzędzia, jak Smarty - system inteligentnych szablonów.
Powyższy przykład przepisany za pomocą Smarty składałby się z dwóch plików. Pierwszy plik, z kontrolerem wyglądałby tak:
$smarty = & new Smarty();
$dataset = array();
while($row = mysql_fetch_assoc($result))
{
array_push($dataset, $row);
}
$smarty->assign('dataset', $dataset);
$smarty->display('data-template.html');
Drugi zaś, zawierający sam szablon:
<table>
{section name="row" loop=$dataset}
<tr>
<td>{$dataset[row].imie}</td>
<td>{$dataset[row].nazwisko}</td>
<td>{$dataset[row].data_urodzenia|
date_format:"%d.%m.%Y"}</td>
</tr>
{/section}
</table>
Największa zaleta tego podejścia - czytelność i uniezależnienie silnika strony od jej wyglądu.
Druga zaleta - reużywalność raz wykonanych szablonów, załóżmy bowiem, że strona zawiera formularz, który należy wypełnić i który jest następnie walidowany po stronie serwera pod kątem poprawności pól. Co jeśli pola nie są wypełnione poprawnie? Niektóre serwisy wyświetlają błąd i przycisk wstecz
- niezbyt elegancka metoda, biorąc pod uwagę, że IE skrupulatnie czyści pola formularza przy wracaniu do strony z historii. Można jednak przygotować jeden formularz:
<form action="/" method="post">
<fieldset>
<legend>Dane osobowe</legend>
<p>Imię:
<input type="text" name="imie"
value="{$smarty.post.imie}"></p>
<p>Nazwisko:
<input type="text" name="nazwisko"
value="{$smarty.post.nazwisko}"></p>
<p>Email:
<input type="text" name="email"
value="{$smarty.post.email}"></p>
</fieldset>
</form>
Następnie wywołać go dwukrotnie - raz przy konieczności jego wypełnienia, drugi raz w funkcji sprawdzającej jego poprawność, jeśli zaistnieje taka potrzeba. Pola pozostaną wypełnione, a użytkownik ograniczy się do poprawienia tylko tych danych, które wprowadzone zostały błędnie.
Trzecia zaleta - system taki pozwala na jednoczesną pracę programistów i webmasterów, szablony można rozwijać równolegle z kodem, co znacznie przyspiesza rozwój serwisu, a czas realizacji jest często kluczowym kryterium przy negocjacjach z klientami.
Hm to brzmi jak skarcenie mojej ostatniej pracy ;-). Ale co tam dopiero zaczynam, a że przydają się nowe pomysły do samo kształcenia więc teraz postaramy się coś z tym zrobić. Tak więc system szablonów, ale wykonany samodzielnie…
Nie warto pisać nowego systemu szablonów. Pracodawca przy zatrudnianiu będzie wymagał znajomości tego, czego się używa na świecie, a nie osiągnięć sportowych.
From TFA:
"Równie kiepskim pomysłem, jak wypluwanie kodu HTML bezpośrednio przez kontroler, jest pisanie własnego silnika szablonowego."
;-P
Bredzicie :-P. Poza tym nie mam na razie nawet w planach pracować w tej branże :-/, PHP to raczej sposób na ożywienie mojej strony domowej i pasja przeplatana z zabawą. Na razie nie mam zamiaru tego zmieniać. Może uda mi się nawet zrobić coś lepszego :-P. Zróbmy rewolucje. Po cholere programować skoro inni już się tym zajeli…
Żeby jeszcze dizajnerzy się Smarty'ego nauczyć chcieli. :)
Programowanie polega nie na wynajdywaniu koła wciąż od nowa, tylko na użyciu istniejących technologii do stworzenia czegoś ciekawego. Zanim zaczniesz pisać coś nowego, zapoznaj się z konkurencją i znajdź jej wady.
No widzisz ale nie mam nawet zamiaru się z tym męczyć. Jest chociaż do tego polska dokumentacja? Czasami lepiej zrobić coś samemu bo wtedy wiesz czego użyłeś w jakim celu. Pozatym nie potrzebny mi kolejny kolos, którego wykorzystanie ograniczy się do mojej strony domowej na której jest raptem kilka wpisów…
A mi się marzy takie coś, co implementuje W3C Document Object Model i na jego podstawie wypluwa kod.
Co do wynajdowania koła… to np. gre też można wykorzystać gotowe biblioteki tylko potem biorą się ludzie nie mający zielonego pojęcia jak to wszystko działa, nie potrafiący optymalizować, dla nich stworzenie grafiki kończy się na wywołaniu kilku funkcji, załadowaniu tekstury…
To dlaczego piszesz w PHP, a nie Assembler CGI albo chociaż C CGI? ;>
A czemu łapiesz mnie za słówka zamiast używam konkretynych arumentów? :> Wypowiedź miała charakter ideowy :-P. PHP wykorzystuje aby tworzyć aplikacje sieciowe, na codzień korzystam z C, kiedyś urozmaicony o niewielkie wstawki w Assemblerze (zresztą nie pisane samemu)… ale wiem co nie co…
Ponieważ zawsze mi się wydawało, że coraz bardziej "programmer-friendly" (czyli coraz wyższego poziomu) języki i biblioteki powstawały właśnie po to, żeby programista mógł skupić się na istocie swojej roboty, a nie szukaniu w którym miejscu wskaźnik wyskoczył o jeden adres za daleko i program się wykrzacza z segmentation fault.
Eckel to ładnie ujął: "dziś czas procesora jest bardzo tani - czas programisty wprost przeciwnie".
Zresztą, Patrys użył argumentu, który jest kompletnie "obok" kwestii łatwość pisania czy optymalizacja - otóż kod napisany w Smarty jest o wiele łatwiejszy do zarządzania i przenoszenia.
Dobra to wyjaśnie się dosadniej, pełno jest głąbów którzy umieją za pomocą Delphi, tudzież innego środowiska Rad stworzyć zegarek i uważają, że umieją programować…
Nie przeczę nie jestem profesjonalistą, dopiero raczkuje ale uważam także, że uczenie się od początku pozwala lepiej poznać istote rzeczy i oto mi chodziło właśnie :-). Nie mówie o wynajdowaniu koła od początku, ktoś mnie może to już pokazać, ale nie chcę czegoś takiego jak telefon do firmy zajmującej się ich produkcją :-).
Co do czasu procesora to jest kwestia sporna, nie lubię takiego podejścia, ale nie przecze skłonny jestem na ustępstwa. Nie będę przecież męczyć się ze zgłębianiem wiedzy o każdym chipie graficznym skoro mam np. OpenGL.
Ale notka Patrysa - jak większość zresztą - przeznaczona jest dla programistów "poważnych", albo jak wolisz - "pracujących". Ci nie mogą sobie pozwolić na robienie czegoś "dla sztuki" czy "bo chcę się nauczyć", bo ich czas (i kiepski kod) kosztuje pracodawcę wymierne kwoty.
Delphi nie używam, ale kilka świetnych rzeczy zrobiono w tym języku/środowisku (kurde, kocham wspólne nazwy dla języków, IDE czy bibliotek). Np. Dev-C++.
To ja powiem tak: lata temu napisałem sobie bibliotekę graficzną w Assemblerze do Pascala. Od początku do końca sam. Umożliwiała stotowanie niewyobrażalnych jak na tamte czasy trybów, z high-colorem i true-colorem włącznie. Dziś, pisząc grę, sięgam po gotowe biblioteki - są sprawdzone, nie poświęcam czasu na ich pisanie i przede wszystkim są przenośne.
Moja uwaga o wynajdywaniu koła: pisz sobie nawet 100 alternatywnych silników szablonowych, ale najpierw poznaj te istniejące. Ewolucja w oprogramowaniu polega na krzyżowaniu i rozwijaniu istniejących rozwiązań i koncepcji, a nie stukaniu w klawiaturę na oślep i tworzeniu drugiego, "własnego" świata od zera.
Patrys: z wyjątkiem oczywiście programów zaliczeniowych i innych edukacyjnych "Hello World!", które są wtórne do bólu ;). Sebas ma rację w jednym - pewne podstawy trzeba poznać, kilka rzeczy trzeba napisać samemu, a dopiero później sięgać po gotowce. Ale potem się zaczynają poważne projekty :].
"Hello World!" wtórne? Przecież stały jest tylko cel, ale implementacje "Hello World!" powstają ciągle nowe, rozwijają się wraz z nowymi technologiami. Przecięż Hello World w BASICu to było:
10 PRINT "Hello World!"
A zrobione przy użyciu nowoczesnych technologii itd. itp. to już jest kilka plików, w kilku językach, z których część trzeba sobie wyklikać, a nie wystarczy z klawiatury wpisać. ;-)
Później początkujący programista PHP widzi takie Hello World, stwierdza, że on umie to znacznie prościej napisać i dalej tworzy po swojemu… Dopiero gdy się przejedzie na jakimś większym projekcie robionym prostackimi metodami, to doceni nowsze technologie, w których Hello World to 20kB kodu, a poważna aplikacja — 30kB. ;-)
No i oczywiście należy stosować narzędzie odpowiednio dobrane to tego co się chce robić. W wielu wypadkach nie ma sensu wysilać się na cokolwiek ambitniejszego niż "print" czy "echo".
A najzabawniejsze w tym wszystkim jest to, że PHP powstało właśnie jako prosty system szablonujący (stąd nazwa), rozrosło się w mocno chaotyczny sposób, po czym — podobnie jak w przypadku JSP, ASP i masy innych narzędzi — okazało się że manie warstwy przetwarzającej HTML najbardziej na zewnątrz to poważny błąd prowadzący do kompletnie zabagnionego, trudnego w utrzymaniu kodu. I teraz jedyna słuszna metoda to pisanie w PHP z całkowitym pominięciem pomysłu, od którego PHP się zaczęło — zewnętrzny procesor HTML jedynie uruchamia kod który najpierw załatwia logikę aplikacji, a później odpala kolejny język szablonujący :)
Rezultat jest taki, że skreśla się jedną z niewielu przewag jakie PHP ma nad innymi językami (szablony na zewnątrz, łatwo pisze się zabawkowe aplikacyjki, ale większość doświadczenia zdobytego przy ich tworzeniu nie pomaga później, bo większe rzeczy i tak trzeba pisać zupełnie inaczej).
hmm.. myślę, że to rozwiązanie ma sens jedyni wtedy jak dwie różne osoby pracują nad php i html.
Pisanie smartowego szablonu tylko dla kliku linii kodu wydaje mi się stratą czasu.. a w przypadku gdy kod ma się powtarzać, napisanie oddzielnej funkcji w php nie zajmie więcej czasu niż napisanie szablonu pod smarta.. proszę o rozjaśnienie jeśli się mylę.
Medyk, piszę w Smartym od niedawna (tak, Patrys mnie wprowadził w temat:)) i zauważyłem, że w Smartym łatwiej i szybciej pisze się wszystkie projekty bardziej skomplikowane od <?php echo 'Hello World!' ?> :).
Chociażby z tej prostej przyczyny, że pisząc w Smartym <a href="qwerty"> wchodzi zupełnie naturalnie, natomiast już w "czystym" php trzeba się chrzanić z doborem cudzysłowiów (gdzie pojedynczy, gdzie podwójny), tudzież sekwencjami ucieczki - które już same z siebie czynią kod niezbyt czytelnym.
Brzmi przekonywująco, co? :)
Co do "dwóch osób" - patrz wyżej na post Vroka. Dezajnerzy o Smartym pojęcia nie mają. Nie mam do nich o to pretensji, iteracja pętli czy inne tablice asocjacyjne to już kwestie programistyczne, a nie naszkicowania layoutu w Dreamweaverze :).
Nie jest to dla mnie bardzo przekonujący argument. W php mamy <?= $x ?> a w smartach {$x}. Taka zmiana nie wygląda mi na rewolucję. Jeszcze tworzenie tych wszystkich plików/szablonów.. w php możemy zrobić zamiast tego funkcje i trzymać je wszystkie w jednym pliku czy całą klasę w razie potrzeby. Wciąż nie jestem przekonany :)
Choć przyznam szczerze, że nie raz nawet to <?= $x ?> jest trochę uciążliwe i fajnie by było zastąpić to czymś prostym (jak w smartach na przykład). Nie mniej przenoszenie zawartości do osobnych plików/szablonów wywoływanie dodatkowych funkcji.. już burzy całą ideę (uczytelnienia - uproszczenia) jak dla mnie. Może istnieje jakaś nakładka na php pozwalająca mieszać kod php i smarty'owy w jednym pliku.. ?
Na postawie obieranych przez dyskutantów podejść dość łatwo rozgraniczyć dla których z nich PHP i inżynieria oprogramowania to niezobowiązująca zabawa a dla których chleb i okrasa :-)
str(): ciekawe do których się załapałem… ;-)
Jajcus: Z radością informujemy Pana, że stanowi Pan chlubny przykład części wspólej obu zbiorów. Nagrodę przyślemy pocztą, proszę nie telefować ;-D
Patrys: wszystko fajnie, ale czy nie lepiej nie byc uzaleznionym od czyjegos rozwiazania (vide: smarty)? Dlaczego nie byc wlasnym pracodawca? Nauka smartow owszem, ale korzystanie z tego na codzien - a fe ;) Wyobraz sobie, ze w wyniku jakiegos strasznie nieprzewidzianego zdarzenia smarty staja sie platne. Wedlug mnie Twoje rozwiazanie to dobre wyjscie dla dewelopera, ktory chce sie zatrudnic i nie ma ambicji ponad to (pewnie sie myle). Kolejna rzecz to taka, ze programowanie nie polega na wynajdywaniu kola, ale samo slowo 'developer' oznacza kogos kto rozwija, rowniez narzedzia, ktore sluza do rozwijania (pogmatwalem) ;] Wiec czy dobrym wyjsciem jest ganienie ludzi za to, ze nie widzac sensu uzywania/rozwijania smartow chca pisac swoj system szablonow od zera?
mroq: zanim się coś nowego napisze, to trzeba wiedzieć jak działa to stare, żeby nie powtarzać błędów. Podejście "ja i tak wiem lepiej" to kiepskie podejście.
Smarty nie może stać się płatne bo jest na GPL i publicznie dostępne, więc jeśli autor postanowi brać pieniądze, to ktoś inny będzie rozwijał za darmo.
Smarty ma architekturę opartą na pluginach i dopisuję własne bardzo regularnie. Mimo wszystko, jeśli ktoś przejmie po mnie projekt to będzie w stanie go kontynuować nie musząc pisać systemu szablonów od zera, bo poprzedniego nie rozumie. "Własne" rozwiązania wiążą się z takim właśnie ryzykiem.
mroq: kwestia kosztów. I pytania — na co chcesz poświęcać swój czas: na tworzenie kodu czy tworzenie aplikacji. To wbrew pozorom nie to samo.
Korzystając z kodu napisanego przez kogoś innego masz mniej do zaprojektowania, napisania, utrzymywania, testowania, odpluskwiania i rozwijania samemu. Zwłaszcza, jeśli jest to coś, czego używa na co dzień duża grupa ludzi — projekty takie jak smarty, z pewną historią i większą społecznością są zwykle dość dobrze dopracowane, a przynajmniej wyklepane do używalności. Jeśli nie z innych powodów, to przynajmniej dlatego że poświęcono na nie olbrzymie ilości czasu i pracy.
A na koniec mądrość ludowa: łatwiej jest napisać nowy marny program niż poznać i zrozumieć istniejący, porządny ;)
A, żeby nie było — Smarty nie używam, PHP staram się unikać, ale też mam na koncie kilka systemów szablonujących. Trochę się nauczyłem od tego czasu :)
patrys: Twój pierwszy argument: nie rozumiem dlaczego powtarzasz wciaz te same frazesy, ktore przeciez w odpowiedzi na moje watpliwosci nie maja racji bytu:
>>Nauka smartow owszem, ale korzystanie z tego na codzien - a fe ;)
Twój drugi argument odnosi się do mojego hipotetycznego wywodu i również nie ma tu znaczenia, bo ja wybiegam hipotezy, a Ty sprowadzasz wszystko do rzeczywistosci, ktora przeciez nie bedzie wieczna.
Twój trzeci argument może być łatwo odparty. Spójrz na IE, przerób ten program tak, zeby byl kompatybilny wstecz, a jednoczesnie mogl konkurowac z FF czy O. Wtedy uwierze, ze tworzenie wlasnych rozwiazan od zera nie ma sensu.
marcink: masz racje, chociaz Twoja madrosc ludowa to chyba wolanie w przestrzen (patrz wyzej odpowiedz na pierwszy argument patrysa).
Z dalszymi komentarzami zapraszam do nowej notki.
smarty za duża kobyła -> polecam smarty-light http://www.paullockaby.com/projects/smarty-light/