Sabloni su na prvi pogled sjajna stvar. Svi koji ih zagovaraju navide najocigledniju prednost: programer pise kod a dizajner dizajnira izgled strane a kad treba izmeniti izgled samo se izmeni sablon.
Sio mu ga Djura...
To jeste tako ali kada su dokumenti jednostavni, odnosno kada ne sadrze linkove ka drugim dokumentima. Ako pogledate sablone nekog iole komplikovanijeg sajta videcete da u tom dzumbusu moze da se snadje samo onaj ko je sajt isprogramirao.
- prvi problem: gubi se WYSIWYG u postupku dizajna
Generalno uzevsi, svaki dokument se sastoji od bar tri sablona: zaglavlja, tela i podnozja, koji se nalaze u odvojenom datotekama i, naravno, tako odvojeni ne lice ni na sta. Dizajnerima, za koje se podrazumeva da korsite neki WSIWYG alat ovakvi sabloni ne vrede mnogo. Kako god okrenu moraju da zarone u kod i u glavi zamisljaju kako stvari treba da izgledaju. Ja se slazem da svaki web dizajner mora da zna da roni po kodu, ali nikako ne mislim da treba ceo posao tako da odradi posto je to najsporiji nacin da se nesto uradi.
- drugi problem: gube se linkovi prema spoljnim dokumentima
Dobra praksa u projektovanju sajta je da se sadrzaj grupise i razmesti po direktorijumima kako bi se znalo gde se sta nalazi i tako lakse radilo azuriranje sadrzaja. Takodje je dobra praksa da su svi linkovi u dokumentima unutar sajta relativni cime se lako manipulise istima aposebno zato sto root sajda u dizajn rezimo i root u eksploataciji najcesce nemaju veze jedno s drugim.
Tako je dobra praksa i da se sami sabloni, s obzirom da su odvojeni od koda, odvoje u poseban direktorijum. E tu je kvaka. Onog trenutka kada smestite sablone u poddirektorijum imate problem.
S cemu se radi: sablon je, kao i svaki drugi klasican html dokument, koji cak moze i sadrzati samo cist html kod. Tako se i likovi prema drugim dokumentima, bitmapama i drugim sadrzajima rade isto kao i u HTML-u i po pravilu se adresiraju relativnim putanjama.
Definisacu relativnu putanju kao putanju koja pokazuje gde se neki dokument nalazi u odnosu na tekucu putanju dokumenta u kome se link nalazi.
Evo jednostavan primer strukture jednog sajta:
/root/
/img/
logo.gif
index.php
-> img/logo.gif
Dakle, index ucitava logotip u sebe relativnom putanjom do njega.
Ako uvedemo sablone struktura sajta ce se malo izmeniti:
/root/
/images/
logo.gif
/templates/
index.tpl
-> ../images/logo.gif
index.php
-> index.tpl
Dodat je direktorijum templates gde se smestaju sabloni. Dizajner ce u njemu napraviti index.tpl i u njega vezati logotip po relativnoj putanji. U toku dizajna tekuca putanja je direktorijum u kome se nalaze sabloni.
Medjutim, kada index.php ucita index.tpl tekuca putanja je putanja na kojoj se nalazi index.php a ne putanja na kojoj se nalazi index.tpl. Kako je tekuca putanja promenjen tako su odmah svi linkovi sa relativnim putanjama postali neispravni i naravno ne rade.
Resenje kome se pribegava je da se u toku dizajniranja sablona unose relativne putanje do dokumenata ali u odnosu na direktorijum u kome se nelazi php skript koji ce ucitavati sablon a ne u odnosu na sam sablon. Takav sablon kada ga skript ucita ce imati ispravne putanje i strana ce biti prikazana kako treba.
Sada imamo situaciju da dizajner mora da radi napamet, jer nijedan spoljasnji element koji korsiti na strani on u toku dizajniranja ne moze da vidi. Ne moze da ga vidi ni WYSIWYG editor sto znaci da gomila prednosti takvih editora biva ponistena. Editor vise ne moze da procita ni sirinu i visinu bitmape koja se nalazi na strani a kamoli da uradi neki drugi pomocni posao kao to je recimo ucitavanje CSS definicije iz spoljasnjeg dokumenta. Prakticno, dizajner pred sobom ima gomilu nabacanih elemenata s kojima vizuelno ne moze da uradi nista nego mora da predje u editor koda i snalazi se po njemu.
Trazio sam po mrezi da li se neko bavio ovim problemom i nisam bas nista nasao. Kada se govori o sablonima prve se hvalospevi o njihovim prednostim ai mogucnostima a stalno se zaboravlja da nas oni istovremeno vracaju u kameno doba web dizajna, kada se sve radilo drvenim ralom. Danas, kada su web dokumenti veoma komplikovani, sadrze mnogo raznorodnih elemenata, cesto veliki broj grafickih elemenata, narocito lejera koji su skoro neupotrebljivi ako ne mozete da vidite na sta lice i mnogo vise skript koda nego samog HTML-a, nemogucnost vizuelnog rada jeste veliki problem.