Dezavantaje vedere în codul de aprindere, blog tarlyun

Nu este un secret că CodeIgniter folosește conceptul de MVC (Model-View-Controller). Afișați sau vizualizați - este responsabil pentru afișarea datelor către utilizator. Principalul avantaj al conceptului MVC este separarea logicii managementului aplicațiilor, a achiziției de date și a afișării. Începând să lucrăm cu CodeIgniter. tu lasati un cod HTML / PHP / SQL intr-un singur loc (inca mai am module de fisiere pentru 5000-7000 linii cu functii hellish in cateva mii de linii). Lucrul cu vizualizarea. nu trebuie să accesați direct modelele. Ar trebui să fie o axiomă pentru tine. Tot ce puteți face în vizualizare este de a procesa datele primite de la controler și de a folosi ajutorul lui.







Să ne uităm la deficiențele implementării de bază a Vizualizării. De exemplu, luați o bucată din documentația: CodeIgniter> Ghidul utilizatorului> Vizualizări

În cele mai multe cazuri, împărțim șablonul în 3 părți: conținutul (care variază în funcție de pagina), tot ceea ce este în fața lui (antet, antete, meniuri, pălărie, etc ...), Și totul după (subsol, subsol, meniu, contacte, etc.).

De obicei, trebuie să obțineți meniul din baza de date. Acest lucru se face aproximativ în felul următor:

Nu este cea mai elegantă și mai frumoasă metodă. De ce am venit la CodeIgniter. Pentru a vă curăța codul și pentru a scăpa de hash-ul SQL / PHP / HTML. Și în cele din urmă, și sa întors la asta.

2. Extensia controlerului de bază.

Felul în care m-am dus acum 3 ani, când am studiat CodeIgniter. Esența metodei este de a muta o piesă repetată de cod într-o metodă a controlerului de bază, care va fi responsabil pentru redarea paginii. Toți controlorii vor moșteni de la o bază. Și pentru a afișa Vizualizare vom folosi noua metoda _render.

Vom dezasambla în ordine. Construcția: funcția publică finală _render:

final - nu vă permite să suprascrieți metoda _render la descendenții clasei MY_Controller. Aceasta este o protecție împotriva schimbărilor accidentale. Dacă brusc trebuie să creați un alt șablon de bază, puteți crea o nouă metodă: _render_ajax (), _render_admin () și așa mai departe.







public - face ca metoda să fie disponibilă în afara clasei.

_render - sublinierea înainte de numele metodei vă permite să creați o metodă protejată CodeIgniter. care nu poate fi apelat în browser.

În cele din urmă, am primit codul mai curat în controlere și am reușit să gestionăm șablonul de ieșire într-un singur loc. Dar, de asemenea, nu este o opțiune ideală, aș dori ceva mai mult. Nu este deloc faptul că aproape toate CMS sau proiecte de pe dezvoltatorii CodeIgniter scriu / descarcă mai întâi soluții care să înlocuiască mecanismul standard de lucru cu View.

În următoarea parte, vom revizui soluțiile gata făcute pentru un control vizual mai ușor și mai sofisticat.

Uita-te deoparte: $ this-> load-> vars ($ data);
Acest lucru va face ca datele $ să fie disponibile din toate afișările încărcate fără a specifica datele care trebuie transmise.
Înainte de a face acest lucru, faceți $ data ['content_view'] = 'some / name';
și cu îndrăzneală întotdeauna apelați la aceeași viziune, spuneți principalele.
în principal scrie
$ this-> load-> view ('header');
$ this-> load-> view ($ content_view) ';
$ this-> load-> view ('footer');

A doua parte este în curs de pregătire, în care va fi o prezentare generală a bibliotecilor de șabloane de la Code Igniter

Am folosit codificatorul timp de patru luni. Înainte de toate metodele descrise mai sus, el însuși a venit. Mă bucur că este o practică obișnuită. Multumesc pentru articolul =)

Da, este, versiunea 2.1.3. Biblioteca descărcat și instalat, CodeIgniter-Layout (scântei), dar cum să-l folosească și nu înțeleg ce a fost, de fapt, este nevoie, de asemenea, nu este foarte clar. Pentru mine, există o singură sarcină, pentru a scăpa de același tip de înregistrări:
$ date ['pagini'] = $ this-> pages_model-> get_pages ();
$ date ['pagini_info'] = $ this-> pages_model-> get_pages_info ($ titlu);
$ date ['categoria'] = $ this-> pages_model-> get_category ($ titlu);
în toate funcțiile controlorului. Problema cu șabloanele pe care le-am decis de mult, în ceea ce privește afișările de încărcare. Există doar o astfel de problemă cu specia. După cum am înțeles, puteți urma calea acestui lucru într-un fel transferând proprietățile metodelor dintr-o clasă într-o altă clasă, așa cum este cazul în exemplul dvs. Dar cum să realizăm acest lucru complet incomprehensibil. Și nu mai este timp să stau câteva luni sau jumătate de an pentru a studia unele biblioteci pentru șabloane obscure, care în viitor nu pot fi utile în practică.

Pentru mine există o singură sarcină, pentru a scăpa de înregistrările de același tip

Faceți datele de proprietate $ în controlerul de bază
În proiectantul controlerului, asociați următoarele:
$ this-> data ['pagini'] = $ this-> pages_model-> get_pages ();
$ this-> data ['pagini_info'] = $ this-> pages_model-> get_pages_info ($ titlu);
$ this-> data ['categoria'] = $ this-> pages_model-> get_category ($ titlu);

Și treceți în loc de $ data $ this-> data într-un șablon.

Un pic greșit înțeles, Faceți datele de proprietate $ în controlerul de bază. Această proprietate de făcut în MY_Controller și apoi să moștenească în alți controlori o clasă cu această proprietate? Și cum să facem această proprietate? La urma urmei, proprietatea trebuie să fie inerentă unui obiect. Și dacă nu creați un obiect, atunci cum să creați o proprietate. Explicați-vă.







Trimiteți-le prietenilor: