Voi spune imediat că am scris deja despre acest subiect aici :. Cu toate acestea, nu toată lumea a înțeles acest material și am decis să mă întorc la el și să scriu totul puțin diferit. Nu este un secret că orice motor serios nu se va amesteca niciodată în codul său HTMLși PHP... Dar, HTMLși PHP codurile sunt foarte strâns interconectate, prin urmare, pentru a nu încălca regulile „bunului gust”, au fost inventate fișiere tpl... Aceste fișiere sunt folosite pentru a stoca Cod HTML cu elemente de șablon care sunt substituite în Cod PHP... Să aruncăm o privire mai atentă folosind fișiere tpl cu un exemplu.

Să luăm cu voi cel mai elementar exemplu - acesta este panoul utilizatorului, unde se află avatarul său și o felicitare pe nume. În primul rând, să creăm fișier tplși să se numească userpanel.tpl... Vă reamintesc că aceasta este doar o piesă Cod HTML cu elemente de șablon:

Buna% name%!

Nimic extraordinar, este doar obișnuit Cod HTML... Numai că în loc de anumite valori există % template_elements%.

Acum să ne ocupăm de Procesare PHP... Totul aici va fi mai mult decât abstract, dar, din păcate, nu există altă cale. Principalul lucru este să înțelegeți cum funcționează. Asa de Cod PHP pentru a procesa cele create fișier tpl:

/ * Această funcție, deși folosește buffere, dar esența este elementară: returnează conținutul fișierului * /
funcția getTemplate ($ nume) (
ob_start (); // Începeți să salvați ieșirea în buffer
include ($ nume. ". tpl"); // Trimiteți conținutul fișierului în buffer
$ text = ob_get_clean (); // Ștergeți tamponul și returnați conținutul
returnează $ text; // Returnează textul din fișier
}
$ nume = "Nikolay"; // Adus de la bază
$ avatar = "avatare / utilizator_15.jpg"; // Adus de la bază
/ * Începe să înlocuiască elementele șablonului cu date reale * /
$ userpanel = str_replace (
matrice (
"% Nume%",
„% avatar%”
),
matrice (
$ nume,
$ avatar
),
getTemplate ("userpanel")
);
echo $ userpanel; // Imprimați rezultatul final
?>

Aceasta este cea mai simplă opțiune. Totul este comentat, deci nu ar trebui să existe întrebări cu privire la acest exemplu. Și, de fapt, orice pagină constă din astfel de blocuri. Sarcina dvs. este să luați blocurile necesare (funcția getTemplate ()), înlocuiți cu datele necesare (funcția str_replace () și datele obținute, de exemplu, din baza de date), apoi conectați pur și simplu toate blocurile, precum șirurile obișnuite, și afișați totul pe pagină.

Cu siguranță fără OOP va fi foarte problematic aici. Veți produce atât de multe condiții (există o mulțime de pagini) încât vă veți confunda rapid. Dar principiul utilizării fișiere tpl Sper că ți-ai dat seama. Apoi, pe cont propriu, gândiți-vă cum să încheiați totul OOP pentru a face totul cât mai simplu posibil în ceea ce privește înțelegerea codului și menținerea acestuia în viitor.

După creație info-fișier, în principiu, subiectul a fost deja definit. Aceasta înseamnă că puteți accesa secțiunea pentru gestionarea temelor http://mysite.ru/admin/build/themesși includeți tema dvs. acolo. Firește, după ce îl porniți, nu veți vedea niciun design - pagina va lua stilul „negru pe alb” - text negru pe un fundal alb.

Cu toate acestea, vreau să observ că, în ciuda faptului că în tema noastră nu există fișiere decât mytheme.info nu minte, site-ul va funcționa ca înainte - afișează tot conținutul, adaugă blocuri în regiuni ( http://mysite.ru/admin/build/block) etc. Acest lucru se datorează faptului că nucleul Drupal include module necesare, care, chiar și în absența fișierelor din tema dvs. (cu excepția fișierului cu informații), vă permit să continuați să lucrați cu Drupal.

În principiu, toată crearea șablonului este redusă la fișiere șablon suprapuse (acestea au extensia .tpl.php) module standard ale noastre CMS.

Cel mai important fișier tpl (tpl este abrevierea șablon, model) este page.tpl.php... El este responsabil pentru construirea fiecărei pagini a site-ului. Să vedem în ce constă fișierul șablon:

• cod html
• cod PHP
• cod javascript(nu este necesar)

Drupal transferă datele site-ului către fiecare fișier șablon sub formă de variabile standard. Există 2 tipuri de variabile pentru fiecare fișier șablon:

• variabile care sunt transmise numai către acest fișier
• variabile care sunt transmise tuturor fișierelor

Iată o listă cu toate variabilele pentru page.tpl.php:

Variabile comune (pentru toate fișierele):

• $ cale_baza- calea de bază unde a fost instalat Drupal
• $ css- o serie de fișiere CSS conectate la fișierul șablon curent
• $ director- calea către folderul în care este instalată tema
• $ is_front- returnează TRUE dacă sunteți pe pagina principală
• $ logged_in- returnează TRUE dacă sunteți autentificat
• $ is_admin- returnează TRUE dacă aveți acces la panoul de administrare

Metadate de pagină

• $ limba- (un obiect) Limba actuală care este afișat pe site
• $ limba-> limbă- conține reprezentarea sa textuală
• $ limba-> dir- conține direcția limbajului. Va fi „ltr” (de la stânga la dreapta) sau „rtl” (de la dreapta la stânga)
• $ head_title- versiune modificată a titlului paginii, pentru utilizare între etichete
• $ cap- inserat între etichete ... Conține metaetichete, Cuvinte cheie etc.
• $ stiluri- servește la descărcarea tuturor css-fișiere către pagina curentă
• $ scripturi- servește la descărcarea tuturor javascript "s la pagina curentă
• $ body_classes- un set de clase css pentru etichetă ... Conține informații despre locația actuală a coloanelor de pe site, numărul acestora, adresa URL „e etc.

Informații despre site

• $ front_page- adresa paginii principale a site-ului. Mai bine să folosiți această variabilă la care să faceți referire pagina principala de cand include limba și prefixul domeniului
• $ siglă- calea către sigla site-ului, dacă este inclusă pe site
• $ site_name- Numele site-ului. Poate fi gol dacă îl dezactivați în funcțiile din fișierul de informații. Configurabil la mysite.ru/admin/settings/site-information
• $ site_slogan- sloganul site-ului. Poate fi gol dacă îl dezactivați în funcțiile din fișierul de informații. Configurabil la mysite.ru/admin/settings/site-information
• $ misiune- misiunea site-ului. Poate fi gol dacă îl dezactivați în funcțiile din fișierul de informații. Configurabil la mysite.ru/admin/settings/site-information

Navigare

• $ search_box- conține cod html care afișează șirul de căutare. Poate fi gol dacă îl dezactivați în fișierul cu informații
• $ linkuri_principale
• $ links_ secundare- o matrice care conține legături de navigare pentru site, dacă acestea sunt permise în caracteristicile fișierului de informații

Conținut implicit al paginii

• $ rămase- regiune. Conține codul html pentru coloana din stânga. Dacă specificați regiuni în fișierul de informații, acesta dispare
• $ pesmet - "firimituri de pâine" pentru pagina curenta
• $ titlu- titlul paginii
• $ ajutor- sfaturi dinamice, mai ales afișate în zona de administrare
• $ mesaje- afișează mesaje despre erori și avertismente pe site
• $ file- linkuri (file) care leagă pagina curentă de subpagini (de exemplu, pentru un articol - cu pagina de editare)
• $ content- conținutul paginii curente
• $ dreapta- regiune. Conține codul html pentru coloana din dreapta. Dacă specificați regiuni în fișierul de informații, acesta dispare

Zona de jos / date de acoperire

• $ feed_icon- linie cu toate pictogramele părere pentru pagina curentă
• $ footer_message- mesaj în partea de jos a paginii. Configurabil la mysite.ru/admin/settings/site-information
• $ subsol- regiune. Conține codul html pentru partea de jos a paginii. Dacă specificați regiuni în fișierul de informații, acesta dispare
• $ inchidere- eticheta de închidere pentru toate modulele care au schimbat pagina. Această variabilă trebuie afișată după tot conținutul dinamic. Cel mai bun înainte de a închide eticheta BODY

Toate sunt enumerate aici variabile standard... Dar puteți adăuga variabilele aici fie ca regiuni info-fisier, sau în orice alt rol prin fișier template.php(despre el puțin mai târziu).

Acum vă voi arăta în ce cod ar trebui să fie page.tpl.phpși în ce cod este apoi interpretat de browsere. Iată o bucată de cod din page.tpl.php:

Prima linie verifică dacă pagina curentă are un titlu. Dacă nu este acolo, atunci depanatorul va sări pur și simplu acest cod și nu îl va introduce. Dacă titlul există, atunci eticheta va fi adăugată la codul html al paginii

, după acesta titlul paginii va fi tipărit și toate acestea vor fi închise cu eticheta

... Dacă priviți codul acestei pagini într-un browser, atunci ar arăta astfel:

Lecția 4. Fișiere necesare pentru a crea un șablon. Page.tpl.php

Aproape toate variabilele de site sunt împachetate în acest fel. Acest lucru este făcut astfel încât să putem stiliza conținutul fără să știm în prealabil care va fi.

Așa arată fișier standard page.tpl.php care vine cu Drupal. Schimbați numele claselor, rearanjați variabilele - și vedeți ce se întâmplă. Acest lucru este necesar pentru a „simți” cum funcționează și ce este afișat ca rezultat.

„- // W3C // DTD XHTML 1.0 Strict // RO” „http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”> „http://www.w3.org/1999/xhtml” xml: lang = "limba?> " lang = "limba?> " dir = "dir?> "> "" >

Dragi prieteni,

Publicăm în continuare o serie de sfaturi utile care facilitează înțelegerea unora dintre acțiunile și caracteristicile scriptului. Recent, am primit adesea întrebări cu o solicitare de modificare a scriptului, astfel încât să putem utiliza diferite șabloane pentru diferite secțiuni ale site-ului. De exemplu, pagina principală cu știri ar trebui să aibă o structură de aspect și, de exemplu, pagina de feedback ar trebui să fie complet diferită. În același timp, motivându-ne că puteți schimba șabloanele din panoul de administrare numai pentru categoriile de știri ale site-ului. Dar, de fapt, toate acestea pot fi implementate folosind mijloace standard, despre care va fi vorba despre acest scurt articol.

Deci, primul lucru de care avem nevoie este să ne referim la documentația scriptului, care spune că șablonul main.tpl acceptă următoarele etichete:

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

de asemenea, această etichetă are un opus

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

Să luăm un exemplu de sarcină ca bază: faceți site-ul să utilizeze un design al șablonului, iar feedback-ul de pe site utilizează altul. Pe această bază, trebuie să deschidem șablonul main.tplși specificați următoarele:

Iată tot textul șablonului care va fi afișat atunci când vizualizați feedback
aici este întregul text al șablonului, care va fi afișat peste tot, cu excepția feedback-ului

Dar acest lucru are un mare dezavantaj, fișierul dvs. principal șablon este main.tpl va fi prea mare pentru că de fapt, va conține două modele diferite și aici ne întoarcem din nou la documentație și scenariu și aflăm despre existența unei etichete frumoase: (include fișier = "my_block.tpl") care conectează fișierul my_block.tpl specificat la șablon.

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

În fișierul șablon feedback_main.tpl facem proiectarea feedback-ului, iar în fișierul all_main.tpl realizăm proiectarea restului site-ului. Atât, este ușor și simplu de implementat, nu trebuie să faceți nicio modificare a scriptului. De asemenea, puteți personaliza designul oricărei secțiuni, puteți combina mai multe secțiuni etc. Citiți documentația pentru scenariu mai des și cu atenție, acolo puteți sublinia o mulțime de informații utile pentru dvs.

Cu sinceritate,

Separarea logicii primirii datelor de logica afișării lor este o parte foarte importantă a dezvoltării web.
Orice programator care s-a ridicat puțin peste nivelul „Hello world” începe să simtă nevoia unei astfel de separări. Dar nu toată lumea ajunge la concluziile și deciziile corecte.
Prin urmare, voi da aici cele mai importante reguli:
1. Codul de primire și codul de afișare a datelor trebuie separate.
2. Orice ieșire ar trebui să înceapă numai după ce toate datele sunt pregătite pentru aceasta.
3. În consecință, orice script ar trebui să se ocupe doar de prelucrarea datelor. După aceea, el poate trimite fie un fel de antet HTTP, fie poate apela șablonul, trimițându-i datele pregătite, sau ambele împreună.
4. Ce motor de șablon de utilizat este al zecelea lucru. Cel mai simplu și mai accesibil este PHP în sine, așa că se vor da exemple pe el.

Iluzii
Probabil că nu există subiect în programarea web care să fie la fel de evident pe cât de neînțeles ca șabloanele. Toată lumea, mai devreme sau mai târziu, ajunge la concluzia că este necesar să utilizați șabloane. Dar vine, dintr-un anumit motiv, prin cele mai sălbatice amăgiri și fantezii.

Cea mai simplă și evidentă concepție greșită este că începătorii apelează un fișier „design”, care este un html obișnuit pentru toate paginile unui site, ca șablon. Și pe aceasta se calmează. Informații dinamice, nimic ezitant, afișând vechiul ecou bun :-)
De fapt, motorul de șabloane 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. „Proiectantul” are nevoie de șabloane pentru a le putea edita fără a fi nevoie 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. Ce este un designer? Aceasta este o persoană care lucrează în Photoshop. Cel mai adesea nu știe deloc HTML. Și fie un designer de layout special, fie - cel mai adesea ... programatorul însuși - lucrează la șablon! Amuzant, nu-i așa?
Acum corolarul, despre separarea PHP de HTML. Excelent. Avem în față scopul sfânt al separării. Prin urmare, venim cu Smarty și scriem:
(foreach key = cid item = con from = $ contacts)
($ con.name) - ($ con.nick)

(/ pentru fiecare)
Chiar și mai amuzant.
„Proiectantul” pentru care a început totul leșină de fericire.

Teorie
Se pare că motivele noastre pentru care am decis să folosim șabloane nu merită un ban. Și ce acum - nu sunt necesare, se pare, șabloane în general? Necesar. Dar mai întâi trebuie să răspundeți la întrebarea - „de ce?” Pentru ce au nevoie de șabloane. Și verificați răspunsul cu practică. Am adresat 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 mandatului meu de programator web, am formulat pentru mine trei motive pentru care personal am nevoie de șabloane. De fapt, sunt două. Și, în cele din urmă, ajunge la un singur lucru:

Un cod - mai multe vizualizări.

De multe ori se întâmplă ca, în loc de o informație, să arătați alta. De exemplu, codul pentru lucrul cu baza de date primește un mesaj de eroare în locul textului de știri. În acest caz, în loc de o pagină de știri, trebuie să afișați una complet diferită - cu scuze și o cerere de a reveni mai târziu. Este foarte ușor să faceți acest lucru cu șabloane.

Adesea, aceleași informații trebuie prezentate în mai multe forme. De exemplu, o pagină obișnuită și o pagină tipărită. Informațiile sunt aceleași, codul de recuperare este același și codul de ieșire este diferit. În fața unei astfel de situații, puteți împărți foarte repede codul dvs. î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ă trimitem informații nu direct în HTML, ci printr-o cerere AJAX, în format JSON. Dacă am folosit un motor șablon, atunci schimbăm exact o linie din codul nostru - apelând motorul șablon la apelând json_encode (). Și dacă rezultatul nostru a fost amestecat cu codul pentru primirea datelor, atunci întregul cod ar trebui rescris!

Situația este oarecum similară: să presupunem că scenariul nostru este pe două site-uri. Plus o copie la noi. Și așa am găsit un bug mare acasă. Închide-l. Acum trebuie să actualizăm codul de pe site-uri. Și iată-l - momentul adevărului: dacă șabloanele au fost utilizate corect, atunci pur și simplu încărcăm codul pe ambele site-uri și totul continuă să funcționeze, de parcă nu s-ar fi întâmplat nimic! Această situație, în opinia mea, este un test ideal al abordării alese pentru modelare.

Un alt punct important pe care mulți oameni îl pierd (în raționamentul lor teoretic, în timp ce îl întâlnesc în mod constant în practică!) - ordinea de execuție a scriptului nu se potrivește întotdeauna cu ordinea de ieșire din șablon... Exemplu de manual - afișarea titlului articolului în etichetă

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

• "target =" _ blank ">




Buna ziua. Vreau să introduc o altă bicicletă scrisă în PHP folosind Modelul de obiect document. În ce se deosebește de alți reprezentanți cu trei roți ai aceleiași specii? De fapt, nu există atât de multe diferențe, acesta combină cele mai bune dintre multe. De exemplu:

1. Separarea completă a html și php.
2. Nu există etichete suplimentare în șabloane precum


3. Posibilitatea 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. Posibilitatea 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 este de utilizat, voi spune și arăta cum l-am folosit pentru a crea unul dintre proiectele mele (bănuiesc că voi rescrie toate proiectele mele 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 obțin conținutul din baza de date și îl salvez în matricea $ page. Și încep să lucrez cu clasa.

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

$ tpl = șablon nou; $ tpl -> ext = TPL_EXTENSION; # extensia fișierelor din directorul șablon $ tpl -> htm = CACHE_EXTENSION; # extensie pentru paginile deja generate $ tpl -> skin_dir = DIR_TEMPLATES; # director care conține toate șabloanele de site (de exemplu șabloane) $ tpl -> js_dir = DIR_JS; # director unde trebuie să căutați fișiere JS $ tpl -> css_dir = DIR_CSS; # director unde se află CSS $ tpl -> img_dir = DIR_IMG; # director unde imagini $ tpl -> skin = $ _SESSION ["skin"]; # numele șablonului pe care vreau să îl folosesc $ tpl -> cache = DIR_CACHE; # unde se salvează html $ tpl terminat -> log = FILE_T_LOGS; # unde să scrieți jurnalele $ tpl -> tag_start = SYMBOL_START_TAG; # Caracterul pe care variabilele din șablon încep cu $ tpl -> tag_end = SYMBOL_END_TAG; # Caracterul care termină variabilele din șablonul $ tpl -> dir_delimeter = DIRECTORY_SEPARATOR; $ tpl -> space = SYMBOL_SPACE; # caracter care înlocuiește un spațiu.
Fuf, se pare că toate variabilele au fost trecute, să mergem mai departe.
Pentru a nu forța clasa să facă o muncă inutilă, verificăm mai întâi dacă avem deja un fișier Html gata făcut din pagina solicitată.
if ($ tpl -> TestPageStatus () === TRUE) (cere $ tpl -> cacheFileName;) else ($ tpl -> pagina ("index"); # trece numele fișierului șablon, apropo, tu pot trece mai multe dintre ele, separate prin virgule $ tpl -> assign ("HEAD", $ head); $ tpl -> assign ("CONTENT", $ page); $ tpl -> build (); # da comanda către construiți șablonul $ tpl -> ShowPage (); # output.)
Iată toate metodele pe care trebuie să le folosiți pentru a afișa pagina.

Acum să analizăm câteva metode mai utile din această clasă. Să presupunem că am trecut deja tot ce ne trebuie clasei, dar nu i-am dat încă o comandă de ieșit, deoarece 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. În primul rând, trebuie să găsim blocul în care dorim să adăugăm ceva. O puteți găsi în 2 moduri:

$ tpl -> findById ("findMe"); $ tpl -> findByTagName ("div");
Metoda findById presupune în mod logic că toate ID-urile etichetei din șablon sunt unice. Și metoda findByTagName va returna prima care se potrivește.
Trebuie să trecem rezultatul obținut căutând în metoda $ tpl -> createChild () pentru a putea crea etichete copil în elementul găsit. Apropo, după crearea unui element nou, metoda createChild 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ă vă voi arăta 3 exemple simultan. Exemplul 1:

Trebuie să creăm

interior

$ părinte = $ tpl -> findById ("părinte"); $ tpl -> createChild ($ părinte, "div", "id = copil, clasă = test");
Primim:


Exemplul 2:

Trebuie să creăm

Un text
interior

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

Un text

Exemplul 3:
Trebuie să creăm

Element nou
în primul element span care vine peste

$ părinte = $ tpl -> findByTagName ("span"); # (1) $ tpl -> createChild ($ parent, "div", "Element nou"); # (2)
(1) Căutarea unui părinte nu după cod, ci după etichetă, va găsi primul care se potrivește
(2) Dacă nu avem nevoie de atribute, ci doar de valoarea noului element, atunci acestea pot fi omise.

Primim:

Element nou

Și după aceste manipulări, am sunat deja ShowPage. Și aici ajungem fără probleme la alte 2 puncte interesante.
Imaginați-vă o situație în care avem un șablon, să presupunem că este un șablon list.tpl cu o listă de, să zicem, telefoane mobile:

(CONTENT.Marca)

(CONTENT.Model)

(CONTENT.Info)

Dacă am transmis informații doar prin intermediul unui telefon, atunci variabilele vor fi pur și simplu înlocuite de valorile lor, iar dacă am transmis informații prin mai multe telefoane simultan, atunci clasa va copia această secțiune de câte ori au venit variantele de valori aceasta. Și o va face el însuși, spre deosebire, de exemplu, de clasa xTemplate, care avea atribuire și analiză pentru fiecare valoare
Este adevărat, există un moment nu prea convenabil, dacă după acest bloc mai sunt și alții, de exemplu:

(CONTENT.Marca)

(CONTENT.Model)

(CONTENT.Info)
Un alt bloc

Apoi, într-o astfel de situație, va trebui să folosim un mic truc prin împachetarea telefonului mobil

(CONTENT.Marca)

(CONTENT.Model)

(CONTENT.Info)
Un alt bloc

În acest caz, toate telefoanele mobile vor apărea unul după altul, în interior
, iar „Un alt bloc” va rămâne mai jos.

Și, dacă nu am uitat nimic, atunci ultimul moment este adăugarea conținutului altor șabloane la șablonul curent.
Apel din nou la imaginația ta.

Imaginați-vă că proiectantul de layout dorește ca conținutul fișierului page.html să fie adăugat la blocul de fișiere list.html, pentru aceasta el adaugă în locul potrivit în fișierul list.html pagină iar când clasa vede această etichetă, o va înlocui cu conținutul fișierului page.html

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

Asta este probabil tot, dacă îmi amintesc ceva, te voi informa suplimentar. Mulțumesc că ai citit până la capăt.

Etichete: php, clasă, șablon, motor șablon, analizor