Tere. Tahan esitleda veel ühte PHP-ga kirjutatud jalgratast dokumendiobjekt Mudel. Mille poolest see erineb teistest sama liigi kolmerattalistest esindajatest? Tegelikult polegi erinevusi nii palju, see ühendab endas parima paljudest. Näiteks:
1. html ja php täielik eraldamine.
2. Tüübimallides pole lisasilte
3. Võimalus küljendusse põimida teiste mallifailide sisu nii php-st kui ka küljenduses spetsiaalset silti kasutades.
4. Võimalus luua mis tahes html-märgendit lennult.
5. Võimalus salvestada html faili kõike, mis loodi ja koguti.
6. Enne malli genereerimist küsitud lehe html-faili olemasolu kontrollimine.
Et kõigile oleks koheselt selge, kui mugav ja lihtne seda kasutada on, räägin ja näitan, kuidas ma seda ühe oma projekti loomisel kasutasin (kahtlustan, et kirjutan selle jaoks kõik oma projektid ümber).
Esimese asjana hankin tavaliselt andmebaasist kogu teabe lehe kohta ( märksõnad, lehe kirjeldus, malli nimi ning css- ja js-failide aadressid). Salvestan selle kõik massiivi $head. Seejärel võtan sisu andmebaasist ja salvestan selle $page massiivi. Ja ma lähen koos klassiga tööle.
Niisiis, kõigepealt helistan klassi konstruktorile ja edastan sellele kõik vajalikud parameetrid:
$tpl = uus mall; $tpl -> ext = TPL_EXTENSION; # faililaiend mallikataloogis $tpl -> htm = CACHE_EXTENSION; # laiendus juba loodud lehtedele $tpl -> skin_dir = DIR_MALLEET; # kataloog, mis sisaldab kõiki saidi malle (näiteks malle) $tpl -> js_dir = DIR_JS; # kataloog, kust JS-faile otsida $tpl -> css_dir = DIR_CSS; # kataloog, kus CSS asub $tpl -> img_dir = DIR_IMG; # kataloog, kus pildid on $tpl -> skin = $_SESSION["nahk"]; # malli nimi, mida soovin kasutada $tpl -> vahemälu = DIR_CACHE; # kuhu valmis html salvestada $tpl -> log = FILE_T_LOGS; # kuhu logid kirjutada $tpl -> tag_start = SYMBOL_START_TAG; # Sümbol, millega malli muutujad algavad $tpl -> tag_end = SYMBOL_END_TAG; # Märk, mis lõpetab muutujad mallis $tpl -> dir_delimeter = DIRECTORY_SEPARATOR; $tpl -> tühik = SYMBOL_Space; # märk, mis asendab tühikut.
Fuf, tundub, et kõik muutujad on üle kantud, lähme edasi.
Selleks, et mitte sundida klassi lisatööd tegema, kontrollime esmalt, kas meil on juba valmis HTML-fail soovitud leheküljest.
if($tpl -> TestPageStatus() === TRUE) ( nõua $tpl -> cacheFileName; ) else ( $tpl -> page("indeks"); # edasta mallifaili nimi, muide, sa saab läbida mitu neist, eraldatuna komadega $tpl -> assign("HEAD",$head); $tpl -> assign("CONTENT",$page); $tpl -> build(); # malli ehitamise käsk $tpl -> ShowPage(); # väljund.)
See on tegelikult kõik meetodid, mida peate lehe kuvamiseks kasutama.
Vaatame nüüd veel paari selle klassi kasulikku meetodit. Oletame, et oleme juba kõik vajaliku klassile edastanud, kuid pole veel andnud talle väljundi käsku, sest järsku meenus, et malli on vaja luua mitu HTML-i silti. Seda on ka väga lihtne teha. Kõigepealt peame leidma ploki, kuhu tahame midagi lisada. Leiate selle kahel viisil:
$tpl -> findById("findMe"); $tpl -> findByTagName("div");
Meetod findById eeldab loogiliselt, et kõik malli ID-sildid on kordumatud. Ja meetod findByTagName tagastab esimese sobiva.
Otsinguga saadud tulemuse peame edastama meetodile $tpl -> createChild(), et saaks leitud elemendis alamsilte luua. Meetod createChild, muide, tagastab pärast uue elemendi loomist selle meile, et saaksime vastloodud elementi kusagil mujal kasutada.
Tutvudes ja katsetades leidsin mallis siltide loomiseks 3 võimalust, seega näitan korraga 3 näidet. Näide1:
Me peame looma
sees$parent = $tpl -> findById("vanem"); $tpl -> createChild($parent,"div", "id=laps, klass=test");
Saame:
Näide 2:
Me peame looma
$parent = $tpl -> findById("vanem"); $tpl -> createChild($parent,"div", "id=laps,klass=test", "Mõned tekstid");
Saame:
Näide3:
Me peame looma
$parent = $tpl -> findByTagName("span"); # (1) $tpl -> createChild($parent, "div", "Uus element"); # (2)
(1) Otsides vanemat mitte ID, vaid sildi järgi, leiab esimese sobiva
(2) Kui me ei vaja atribuute, vaid ainult uue elemendi väärtust, siis ei saa neid edasi anda
Saame:
Ja pärast neid manipuleerimisi helistan juba ShowPage'ile. Ja siin lähenesime sujuvalt veel 2 huvitavale punktile.
Kujutagem ette olukorda, kus meil on mall, oletame, et see on list.tpl mall, mis sisaldab näiteks mobiiltelefonide loendit:
(SISu bränd)
(SISU.Mudel)
(SISU.Info)Kui edastasime infot ainult 1 telefoniga, siis muutujad asendatakse lihtsalt nende väärtustega ja kui edastasime infot korraga mitme telefoniga, siis klass kopeerib seda jaotist nii mitu korda, kui on väärtusvalikuid saanud. Ja ta teeb seda ise, erinevalt näiteks klassist xTemplate, mis pidi iga väärtuse jaoks kutsuma assign ja parse
Tõsi, on üks mitte eriti mugav hetk, kui pärast seda plokki on veel mõned, näiteks:
(SISu bränd)
(SISU.Mudel)
(SISU.Info)Siis peame sellises olukorras kasutama väikest nippi mobiiltelefoni pakkides
(SISu bränd)
(SISU.Mudel)
(SISU.Info)Sel juhul ilmuvad kõik mobiiltelefonid üksteise järel sisse , ja "Mõni muu plokk" jääb alla.
Ja kui ma pole midagi unustanud, siis viimane hetk on lisada praegusele mallile teiste mallide sisu.
Ma apelleerin taas teie kujutlusvõimele.
Kujutage ette, et küljenduskujundaja soovib, et faili page.html sisu lisataks faili list.html plokki, selleks lisab ta faili list.html õigesse kohta
Selliste vahetükkide arv ei ole piiratud ja nende asukoht pole absoluutselt kriitiline, nii et saate neid sisestada nii, nagu soovite ja mis tahes koguses.
See on ilmselt kõik, kui midagi meenub, siis annan teada. Täname, et lugesite lõpuni.
Sildid: php, klass, mall, mallimootor, parser
Pärast loomist info-fail, põhimõtteliselt on teema juba määratletud. See tähendab, et saate minna teemahalduse jaotisesse http://mysite.ru/admin/build/themes ja lisage oma teema sinna. Loomulikult ei näe te pärast selle sisselülitamist kujundust - leht omandab stiili "must valgel" - must tekst valgel taustal.
Siiski tahan märkida, et hoolimata asjaolust, et meie teemas pole muid faile peale mytheme.info ei valeta, sait töötab nagu varem – kuvage kogu sisu, lisage piirkondadele plokid ( http://mysite.ru/admin/build/block) Ja nii edasi. See on tingitud asjaolust, et Drupali tuum sisaldab vajalikud moodulid, mis võimaldavad teil Drupaliga tööd jätkata isegi siis, kui teie teemas pole ühtegi faili (välja arvatud teabefail).
Põhimõtteliselt taandub kogu malli loomine kattuvatele mallifailidele (neil on laiend .tpl.php) meie standardmoodulid CMS.
Kõige olulisem tpl-fail (tpl on lühend sõnadest malli, muster) on page.tpl.php. Ta vastutab saidi iga lehe loomise eest. Vaatame, millest mallifail koosneb:
- html kood
- php kood
- javascripti kood(ei ole vajalik)
Drupal edastab saidiandmed igale mallifailile standardsete muutujate kujul. Iga mallifaili jaoks on kahte tüüpi muutujaid:
- muutujad, mis edastatakse ainult sellele failile
- muutujad, mis edastatakse kõikidele failidele
Siin on loend kõigist muutujatest page.tpl.php:
Üldised muutujad (kõikide failide jaoks):
- $base_path- baastee, kuhu Drupal installiti
- $css- praeguse mallifailiga ühendatud css-failide massiiv
- $kataloog- tee kausta, kuhu teema installitakse
- $is_front- tagastab TRUE, kui olete avalehel
- $logged_in- tagastab TRUE, kui olete sisse logitud
- $is_admin- tagastab TRUE, kui teil on administraatori juurdepääs
Lehe metaandmed
- $keel- (objekt) Praegune keel mis kuvatakse saidil
- $keel->keel- sisaldab selle teksti esitust
- $keel->rež- sisaldab keele suunda. See on kas "ltr" (vasakult paremale) või "rtl" (paremalt vasakule)
- $head_title- lehe pealkirja muudetud versioon, kasutamiseks siltide vahel
- $pea- sisestatud siltide vahele . Sisaldab metasilte, märksõnu jne.
- $stiilid- võimaldab kõike alla laadida css- failid praegusele lehele
- $scripts- võimaldab kõike alla laadida javascript" s praegusele lehele
- $body_classes- klasside komplekt css sildi jaoks . Sisaldab teavet saidi veergude praeguse asukoha, nende numbri, praeguse URL-i "e" jne kohta.
Teave saidi kohta
- $esileht- saidi avalehe aadress. Viitamiseks on parem kasutada seda muutujat avaleht, sest see sisaldab domeeni keelt ja eesliidet
- $logo- saidi logo tee, kui see on saidile lisatud
- $saidi_nimi- saidi nimi. Võib olla tühi, kui teabefaili funktsioonides on see keelatud. Seadistatud saidil mysite.ru/admin/settings/site-information
- $site_slogan- saidi hüüdlause. Võib olla tühi, kui teabefaili funktsioonides on see keelatud. Seadistatud saidil mysite.ru/admin/settings/site-information
- $missioon- saidi missioon. Kui teabefaili funktsioonid on keelatud, võib see olla tühi. Seadistatud saidil mysite.ru/admin/settings/site-information
Navigeerimine
- $otsingukast- sisaldab html-koodi, mis kuvab otsinguriba. Võib olla tühi, kui lülitate selle teabefailis välja
- $primary_links
- $sekundaarsed_lingid- saidi navigeerimislinke sisaldav massiiv, kui need on teabefaili funktsioonides lubatud
Lehe vaikesisu
- $jäänud- piirkond. Sisaldab vasakpoolse veeru html-koodi. Kui määrate teabefailis piirkonnad, siis see kaob
- $leivapuru - "leivapuru" jaoks Käesolev lehekülg
- $tiitel- lehe pealkiri
- $abi- dünaamilised näpunäited, enamasti kuvatakse administraatoripaneelil
- $sõnumeid- Kuvab saidil vea- ja hoiatusteateid
- $tabs- lingid (vahekaardid), mis ühendavad praeguse lehe selle alamlehtedega (näiteks artikli jaoks - selle redigeerimislehega)
- $sisu- praeguse lehe sisu
- $õige- piirkond. Sisaldab parempoolse veeru html-koodi. Kui määrate teabefailis piirkonnad, siis see kaob
Alumine ala/sulgemisandmed
- $feed_icon- rida kõigi ikoonidega tagasisidet praeguse lehe jaoks
- $footer_message- teade lehe allosas. Seadistatud saidil mysite.ru/admin/settings/site-information
- $jalus- piirkond. Sisaldab lehe alaosa html-koodi. Kui määrate teabefailis piirkonnad, siis see kaob
- $sulgemine- sulgemissilt kõikidele lehekülge muutnud moodulitele. See muutuja tuleb kuvada pärast kogu dünaamilist sisu. Parim enne BODY sildi sulgemist
Kõik on siin loetletud standardmuutujad. Kuid siin saate oma muutujaid lisada kas piirkondadena info-faili või mõnes muus rollis faili kaudu mall.php(tema kohta veidi hiljem).
Nüüd näitan, milline kood peaks olema page.tpl.php ja mis koodi seda siis brauserid tõlgendavad. Siin on osa koodist page.tpl.php:
Esimene rida kontrollib, kas praegusel lehel on üldse pealkiri. Kui seda seal pole, jätab silur selle koodi lihtsalt vahele ega lähe sellesse. Kui pealkiri on olemas, siis lisatakse silt lehe html koodile
, pärast seda trükitakse lehe pealkiri ja kogu asi suletakse sildiga
. Kui vaatate selle lehe koodi brauseris, näeks see välja järgmine:
4. õppetund Malli loomiseks vajalikud failid. Page.tpl.php
Peaaegu kõik saidi muutujad mähitakse sel viisil. Seda tehakse selleks, et saaksime sisule stiile ette kirjutada, teadmata ette, milline see olema saab.
See näeb välja selline standardfail page.tpl.php mis on Drupaliga kaasas. Muutke klasside nimesid, korraldage muutujad ümber – ja vaadake, mis juhtub. See on vajalik selleks, et "tunnetada", kuidas see toimib ja mis sellest välja tuleb.
"-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/1999/xhtml" xml:lang= "keel ?>" lang= "keel ?>" dir = "dir ?>">
"alt="(!LANG:"
/>
"title="(!LANG:"rel="kodu">print $saidi_nimi ; ?>
Andmete hankimise loogika eraldamine kuvamise loogikast on veebiarenduse väga oluline osa.
Iga programmeerija, kes on tõusnud veidi kõrgemale "Tere maailm" tasemest, hakkab tundma vajadust sellise eraldatuse järele. Kuid mitte kõik ei tee õigeid järeldusi ja otsuseid.
Seetõttu annan siin kõige olulisemad reeglid:
1. Vastuvõtukood ja andmete kuvamise kood peavad olema eraldatud.
2. Väljamaksmist tuleks alustada alles pärast seda, kui kõik andmed on selleks valmis.
3. Sellest tulenevalt peaks iga skript käsitlema ainult andmetöötlust. Pärast seda võib see saata mõne HTTP-päise või helistada mallile, edastades sellele ettevalmistatud andmed või mõlemat.
4. Millist mallimootorit kasutada, on kümnes asi. Kõige lihtsam ja ligipääsetavam on PHP ise, seega tuuakse selle kohta näiteid.
Pettekujutused
Tõenäoliselt pole veebiprogrammeerimises ühtegi teemat, mis oleks nii ilmselge kui arusaamatu kui mallid. Igaüks jõuab varem või hiljem järeldusele, et malle on vaja kasutada. Kuid see tuleb mingil põhjusel läbi kõige pöörasemate pettekujutluste ja fantaasiate.
Lihtsaim ja ilmsem eksiarvamus on see, et algajad nimetavad eraldi faili paigutatud malli "kujunduseks" - see on saidi kõigi lehtede ühine html. Ja selle peale nad rahunevad. Dünaamiline teave, kõhklemata, väljastades vana head kaja :-)
Tegelikult tegeleb mallimootor peamiselt saidi lehtede muutuva sisu kuvamisega. Ja "disaini" järeldus on teisejärguline ülesanne.
On kaks peamist fantaasiat:
1. Mallid on "disaineril" vajalikud selleks, et ta saaks neid muuta ilma PHP-st aru saamata.
2. Seetõttu on mallide eesmärk PHP-st HTML-ist eraldamine.
Proovime mõelda esimese väite peale. Kes on disainer? See on inimene, kes töötab Photoshopis. Enamasti ei tunne ta HTML-i üldse. Ja malli kallal töötab kas spetsiaalne küljendaja või - enamasti ... programmeerija ise! Naljakas, kas pole?
Nüüd tagajärg, PHP eraldamine HTML-ist. Hästi. Meie ees on eraldamise püha eesmärk. Seetõttu leiutame Smarty ja kirjutame:
(foreach key=cid item=con from=$contacts)
($con.name) – ($con.nick)
(/igaühele)
Veelgi naljakam.
"Disainer", kelle jaoks kõik alustati, minestab õnnest.
teooria
Selgub, et meie põhjused, miks me mallide kasuks otsustasime, pole sentigi väärt. Ja mis nüüd - malle üldiselt pole vaja? Vajalik. Kuid kõigepealt peate vastama endale küsimusele - "miks?" Milleks malle on vaja. Ja kontrolli vastust praktikaga. Olen seda küsimust inimestelt korduvalt küsinud. Kuid peaaegu keegi ei saa sellele vastata. Miks ta malle vajab. Selgub, et inimesed teevad midagi, teadmata, miks.
See on kõige naljakam asi.
Olen oma veebiprogrammeerija karjääri jooksul sõnastanud enda jaoks kolm põhjust, miks ma isiklikult malle vajan. Tegelikult on neid kaks. Kuid lõpuks taanduvad nad ühele asjale:
Üks kood – mitu vaadet.
Tihti juhtub, et ühe teabe asemel on vaja näidata teist. Näiteks andmebaasiga töötamise kood saab uudisteksti asemel veateate. Sel juhul tuleb uudistelehe asemel näidata hoopis teistsugust - vabanduse ja palvega hiljem tagasi tulla. Mallid muudavad selle lihtsaks.
Sageli tuleb sama teavet näidata mitmel kujul. Näiteks - tavaline leht ja leht printimiseks. Teave on sama, selle vastuvõtmise kood on sama, kuid väljundkood on erinev. Sellise olukorraga silmitsi seistes jagate oma koodi väga kiiresti kaheks osaks, millest üks vastutab väljundi eest ja teine ei vastuta. Teine näide: oletame, et soovisime kuvada teavet mitte otse HTML-is, vaid AJAX-i päringu kaudu JSON-vormingus. Kui kasutasime mallimootorit, siis muudame oma koodis täpselt ühe rea - mallimootori kutsumine json_encode() kutsumiseks. Ja kui meil oleks väljund segatud andmete hankimise koodiga, siis kogu kood tuleks ümber kirjutada!
Olukord on mõnevõrra sarnane: oletame, et meie skript on kahel saidil. Lisaks koju koopia. Ja siit kodust leidsime suure putuka. Nad naelutasid teda. Nüüd peame saitide koodi värskendama. Ja siin see on - tõehetk: kui malle kasutati õigesti, laadime lihtsalt koodi mõlemale saidile üles ja kõik töötab edasi, nagu poleks midagi juhtunud! Selline olukord on minu arvates ideaalne proovikivi valitud mallimisviisile.
Veel üks oluline punkt, mida paljud kahetsevad (oma teoreetilises arutluskäigus, puutudes sellega pidevalt kokku praktikas!) - skripti täitmisjärjestus ei ühti alati mallis oleva väljundjärjestusega. Õpiku näide – artikli pealkirja kuvamine sildis