Tpl șabloane php cum se utilizează. Clasă PHP pentru construirea de șabloane

Salutare tuturor. Aș dori să vă prezint o altă bicicletă scrisă în PHP folosind Document Object Model. Cum este diferit de alți reprezentanți cu trei roți ai aceleiași specii? Într-adevăr, nu există atât de multe diferențe, combină tot ce este mai bun din multe. De exemplu:

1. Separarea completă a html și php.
2. Fără etichete suplimentare în șabloanele de tip

3. Abilitatea de a încorpora conținutul altor fișiere șablon în aspect, atât din PHP, cât și folosind o etichetă specială în aspect.
4. Abilitatea de a crea orice etichetă html din mers.
5. Posibilitatea de a salva tot ceea ce a fost generat și colectat într-un fișier html.
6. Verificarea existenței fișierului html al paginii solicitate înainte de generarea șablonului.

Pentru a clarifica imediat tuturor cât de convenabil și ușor de utilizat este, voi spune și arăta cum l-am folosit pentru a crea unul dintre proiectele mele (bănuiesc că îmi voi rescrie toate proiectele pentru el).

Primul lucru pe care îl fac de obicei este să obțin toate informațiile din baza de date despre pagină ( cuvinte cheie, descrierea paginii, numele șablonului și adresele fișierelor css și js). Salvez toate acestea în matricea $head. Apoi, primesc conținutul din baza de date și îl salvez în matricea $page. Și încep să lucrez cu clasa.

Deci, mai întâi apelez constructorul clasei și îi transmit toți parametrii necesari:

$tpl = șablon nou; $tpl -> ext = TPL_EXTENSION; # extensia fișierelor din directorul șablonului $tpl -> htm = CACHE_EXTENSION; # extensie pentru paginile deja generate $tpl -> skin_dir = DIR_TEMPLATES; # directorul care conține toate șabloanele de site (de exemplu șabloane) $tpl -> js_dir = DIR_JS; # directorul unde se caută fișierele JS $tpl -> css_dir = DIR_CSS; # directorul în care se află CSS-ul $tpl -> img_dir = DIR_IMG; # directorul în care imaginile sunt $tpl -> skin = $_SESSION["skin"]; # numele șablonului pe care vreau să-l folosesc $tpl -> cache = DIR_CACHE; # unde să salvezi html terminat $tpl -> log = FILE_T_LOGS; # unde să scrieți jurnalele $tpl -> tag_start = SYMBOL_START_TAG; # Caracterul cu care încep variabilele din șablon $tpl -> tag_end = SYMBOL_END_TAG; # Caracterul care termină variabilele în șablonul $tpl -> dir_delimeter = DIRECTORY_SEPARATOR; $tpl -> spatiu = SYMBOL_SPACE; # caracter care înlocuiește spațiul.
Uf, se pare că toate variabilele au fost transferate, să mergem mai departe.
Pentru a nu forța clasa să facă lucrări inutile, mai întâi verificăm dacă avem deja un fișier HTML gata făcut pentru pagina solicitată.
if($tpl -> TestPageStatus() === TRUE) ( necesită $tpl -> cacheFileName; ) else ( $tpl -> page("index"); # trecem numele fișierului șablon, apropo, poti trece mai multe dintre ele, separate prin virgula $tpl -> assign("HEAD",$tpl -> assign("CONTENT",$tpl -> build();); pentru a construi șablonul $tpl -> ShowPage();
Acestea sunt de fapt toate metodele care trebuie folosite pentru a afișa pagina.

Acum să ne uităm la câteva metode mai utile din această clasă. Să presupunem că am trecut deja tot ce este necesar clasei, dar nu i-am dat încă o comandă la ieșire, pentru că ne-am amintit brusc că trebuie să creăm mai multe etichete Html în șablon. Acest lucru este, de asemenea, foarte ușor de făcut. Mai întâi trebuie să găsim blocul în care vrem să adăugăm ceva. Îl poți găsi în 2 moduri:

$tpl -> findById("findMe"); $tpl -> findByTagName("div");
Metoda findById implică în mod logic că toate ID-urile etichetelor din șablon sunt unice. Și metoda findByTagName va returna prima care se potrivește.
Trebuie sa trecem rezultatul pe care l-am obtinut prin cautare la metoda $tpl -> createChild() pentru a putea crea tag-uri copil in elementul gasit. Metoda createChild, de altfel, după crearea unui nou element, ni-l returnează, astfel încât să putem folosi elementul nou creat în altă parte.

Cercetând și experimentând, am găsit 3 moduri de a crea etichete într-un șablon, așa că voi arăta 3 exemple deodată. Exemplul 1:

Trebuie să creăm în interior

$parent = $tpl -> findById("părinte");
$tpl -> createChild($parent,"div", "id=child, class=test");

Primim:

Exemplul 2:

Trebuie să creăm ceva text înăuntru
$tpl -> createChild($parent,"div", "id=child, class=test");

$parent = $tpl -> findById("părinte");

$tpl -> createChild($parent,"div", "id=child,class=test", "Some text");
Un text

Exemplul 3:
Trebuie să creăm un element New în primul element span
$parent = $tpl -> findByTagName("span"); # (1) $tpl -> createChild($parent, "div", "New element"); # (2)

(1) Căutarea unui părinte nu după id, ci după etichetă va găsi primul potrivit

(2) Dacă nu avem nevoie de atribute, ci doar de valoarea noului element, atunci acestea nu trebuie să fie transmise
Primim:
Element nou

Și după aceste manipulări am apelat deja la ShowPage. Și aici ajungem treptat la încă 2 puncte interesante.

Să ne imaginăm o situație în care avem un șablon, să presupunem că este un șablon list.tpl cu o listă de, să zicem, telefoane mobile:

Și după aceste manipulări am apelat deja la ShowPage. Și aici ajungem treptat la încă 2 puncte interesante.

Să ne imaginăm o situație în care avem un șablon, să presupunem că este un șablon list.tpl cu o listă de, să zicem, telefoane mobile:

Și după aceste manipulări am apelat deja la ShowPage. Și aici ajungem treptat la încă 2 puncte interesante.

Să ne imaginăm o situație în care avem un șablon, să presupunem că este un șablon list.tpl cu o listă de, să zicem, telefoane mobile:

Și, dacă nu am uitat nimic, ultimul lucru este să adaug conținutul altor șabloane la șablonul curent.
Fac din nou apel la imaginația ta.

Imaginează-ți că designerul de aspect dorește ca conținutul fișierului page.html să fie adăugat la blocul fișierului list.html, pentru asta adaugă pagina în locul potrivit în fișierul list.html și când clasa vede această etichetă îl va înlocui cu conținutul fișierului page.html

Numărul de astfel de inserții nu este limitat și locația lor nu este absolut critică, așa că le puteți introduce după cum doriți și în orice cantitate.

Probabil asta e tot, dacă îmi amintesc ceva, te voi anunța în plus. Vă mulțumesc că ați citit până la capăt.

Etichete: php, clasă, șablon, motor de șabloane, parser

Dragi prieteni,

continuăm publicarea seriei sfaturi utile, facilitând înțelegerea unora dintre acțiunile și caracteristicile scenariului. În ultimul timp, am primit deseori întrebări care ne ceru să modificăm scriptul astfel încât să putem folosi diferite șabloane pentru diferite secțiuni ale site-ului. De exemplu pagina de start cu știri ar trebui să aibă o singură structură de aspect, dar de exemplu pagina de feedback ar trebui să aibă una complet diferită. În același timp, motivându-ne că șabloanele pot fi modificate în panoul de administrare doar pentru categoriile de știri ale site-ului. Dar, de fapt, toate acestea pot fi realizate mijloace standard, despre ce este vorba în acest scurt articol.

Deci, primul lucru pe care trebuie să-l facem este să ne referim la documentația de script, care afirmă că șablonul main.tpl acceptă următoarele etichete:

Text care afișează text inclus în etichete dacă este vizualizată secțiunea specificată a site-ului

Text care afișează text inclus în etichete dacă este vizualizată orice secțiune, alta decât cea specificată

Iată întregul text al șablonului care va fi afișat la vizualizarea feedback-ului
aici este întregul text al șablonului, care va fi afișat peste tot, cu excepția feedback-ului

Pe baza tuturor celor de mai sus, implementarea finală arată astfel:

Cu stimă,

Concepții greșite
Probabil că nu există niciun subiect în programarea web care să fie la fel de evident și de neînțeles precum șabloanele. Toată lumea, mai devreme sau mai târziu, ajunge la concluzia despre necesitatea de a folosi șabloane. Dar dintr-un anumit motiv vine prin niște iluzii și fantezii sălbatice.

Cea mai simplă și mai evidentă concepție greșită este că începătorii numesc un „design” plasat într-un fișier separat - un html comun pentru toate paginile site-ului - ca șablon. Și se calmează cu asta. Informații dinamice, fără nicio ezitare, emise de vechiul ecou bun :-)
De fapt, motorul de șablon se preocupă în principal de afișarea conținutului în schimbare al paginilor site-ului. Iar concluzia „proiectării” este o sarcină secundară.

Există două fantezii principale:
1. „Designerul” are nevoie de șabloane pentru a le putea edita fără să înțeleagă PHP.
2. Prin urmare, șabloanele servesc la separarea PHP de HTML.

Să încercăm să ne gândim la prima afirmație. Cine este designer? Aceasta este o persoană care lucrează în Photoshop. Cel mai adesea el nu cunoaște HTML deloc. Și fie un designer special de layout, fie - cel mai adesea... programatorul însuși lucrează la șablon! E amuzant, nu-i așa?
Acum o consecință a separării PHP de HTML. Mare. Avem un scop sacru de separat. Prin urmare, venim cu Smarty și scriem:
(foreach key=cid item=con from=$contacts)
($con.name) - ($con.nick)

(/foreach)
Chiar mai amuzant.
„Designerul”, de dragul căruia totul a început, leșină de fericire.

Teorie
Se pare că motivele noastre pentru care am decis să folosim șabloane nu merită un ban. Și ce acum - se dovedește că șabloanele nu sunt deloc necesare? Necesar. Dar mai întâi trebuie să răspunzi la întrebarea - „de ce?” Pentru ce nevoie de șabloane. Și verifică răspunsul cu practică. Le-am pus oamenilor această întrebare de multe ori. Dar aproape nimeni nu poate răspunde. De ce are nevoie de șabloane? Se pare că oamenii fac ceva fără să știe de ce.
Acesta este cel mai amuzant lucru.

În timpul activităților mele de programator web, mi-am formulat trei motive pentru care personal am nevoie de șabloane. De fapt, sunt două. Și până la urmă se reduce la un singur lucru:

Un cod - mai multe vizualizări.

Se întâmplă adesea ca în loc de o informație să fie necesar să se arate alta. De exemplu, codul pentru lucrul cu baza de date primește un mesaj de eroare în loc de textul știrilor. În acest caz, în loc de o pagină de știri, trebuie să afișați una complet diferită - cu scuze și cu o cerere de a reveni mai târziu. Cu ajutorul șabloanelor acest lucru se face cu ușurință.

Adesea, aceeași informație trebuie afișată în mai multe forme. De exemplu, o pagină obișnuită și o pagină tipărită. Informația este aceeași, codul de primire este același, dar codul de ieșire este diferit. Când vă confruntați cu o astfel de situație, vă veți împărți foarte repede codul în două părți, dintre care una este responsabilă pentru ieșire, iar a doua nu este responsabilă. Un alt exemplu: să presupunem că am vrut să afișăm informații nu direct în HTML, ci printr-o solicitare AJAX, în format JSON. Dacă am folosit un motor de șabloane, atunci schimbăm exact o linie din codul nostru - apelând motorul de șabloane la apelarea json_encode() . Și dacă rezultatul nostru ar fi amestecat cu codul pentru obținerea datelor, atunci întregul cod ar trebui rescris!

Situația este oarecum similară: să presupunem că scriptul nostru este pe două site-uri. Plus că avem un exemplar acasă. Și apoi acasă am găsit un bug mare. L-au sigilat. Acum trebuie să actualizăm codul de pe site-uri. Și iată-l - momentul adevărului: dacă șabloanele au fost folosite corect, atunci pur și simplu încărcăm codul pe ambele site-uri și totul continuă să funcționeze ca și cum nimic nu s-ar fi întâmplat! Această situație, în opinia mea, este un test ideal al abordării alese pentru șablonare.

Un alt punct important pe care mulți oameni îl scapă (în raționamentul lor teoretic, în timp ce îl întâlnesc constant în practică!) este că ordinea de execuție a scriptului nu coincide întotdeauna cu ordinea de ieșire din șablon. Un exemplu de manual este afișarea titlului articolului în etichetă. Dacă afișăm informații pe măsură ce sosesc, pur și simplu nu putem face asta - antetul site-ului deja retras până când am început să primim textul știrii.

De asemenea, trebuie amintit că, pe lângă textul PHP, scripturile scot și antete HTTP. Care trebuie afișat înaintea oricărui text, sau chiar în loc de text (dacă, de exemplu, dorim să redirecționăm utilizatorul către o altă pagină). Dacă implementăm mai întâi logica aplicației fără a scoate nimic, atunci producerea antetului HTTP necesar nu va fi o problemă pentru noi.

Este posibil să aveți propriile motive pentru a utiliza șabloane. Dar cu o singură condiție - aceste motive trebuie să fie cauzate de o necesitate reală, vitală, și nu de „considerații mai înalte” și preocupare pentru unii oameni necunoscuti pentru tine.

Practica
Acum să trecem de la teorie la practică.
În cel mai simplu caz, atunci când afișăm orice pagină, vom avea întotdeauna implicate două șabloane: un șablon general de site și un șablon de conținut pentru o anumită pagină.
Să presupunem că vrem să facem o pagină cu link-uri către site-urile prietenilor.
În acest caz, codul simplificat va arăta astfel:

Fișierul links.php în sine. Nu scoate NIMIC. Pregătește doar datele și apoi apelează șablonul.

La locul potrivit, șablonul paginii noastre este inclus în el (tpl_links.php):

• " />