În ultimii ani, munca mea a fost legată de utilizarea CMS Drupal. dar la petrecere a timpului liber am studiat și doar pentru proiecte distractive am avut parte de cadrele Django ale Python. Flage și Twisted. Acum am decis să învăț bazele a două sau trei cadre PHP populare, iar prima oară am decis să studiez Zend Framework 2 și Yii.
După ce am digerat toate aceste informații, am ajuns la concluzia că tutorialul oficial este destul de uscat în cadrul:
- nu vorbește despre lucrul cu utilizatorii, sesiunile și drepturile de acces,
- doar o astfel de parte fundamentală a cadrului ca ServiceManager este considerată,
- Ca interfață cu baza de date, modelul Table Gateway (și implementarea corespunzătoare în cadru) este utilizat fără altă alternativă.
- Utilizează un motor șablon construit în cadru, care după Jinja 2 al lui Python pare complet incomod și primitiv,
- și așa mai departe.
Ca rezultat, aș putea crea o aplicație mai mult sau mai puțin satisfăcătoare după funcționalitate după citirea cărții.
În acest articol vreau să dau un exemplu de dezvoltare a unui blog simplu, acesta va avea mai multe diferențe față de tutorialul oficial. În primul rând, voi încerca să mă concentrez asupra acelor aspecte care în timpul studiului mi s-au părut insuficient dezvăluite în tutorialul oficial. În plus, voi folosi câteva tehnologii alternative celor utilizate în cadrul implicit al lui Zend:
- în prima (actuală) parte, mă voi uita la structura ZendSkeletonApplication,
- În partea a doua, voi dezvolta dezvoltarea propriului meu modul (formulare, lucrul cu DB cu Doctrina ORM, dezvoltarea View-plug-in-ului),
- Partea a treia va fi dedicată colaborării cu utilizatorii.
În textul articolului vor fi uneori linkuri către sursele de aplicații sau fișiere externe generate automat de compozitor. În repozitoriul acestor fișiere acolo, deci pentru un studiu mai aprofundat al aplicației dezvoltate în acest tutorial, va trebui să instalați singur software-ul necesar.
ZendSkeletonApplication
(dacă este configurat corespunzător, comanda php compozitor.phar poate fi înlocuită pur și simplu cu un compozitor, dar mai târziu în articol voi da prima opțiune ca fiind mai universală)
După executare, veți primi o aplicație cu următoarea structură (am lăsat numai cele mai interesante directoare și fișiere):
Să analizăm în detaliu directoarele și fișierele create.
Structura proiectului
composer.json
Să începem cu fișierul composer.json din rădăcina proiectului. Are următoarea formă:
Acest fișier specifică setările aplicației care vor fi utilizate de Compozitor. Partea cea mai interesantă a acestei configurații este secțiunea necesită, care conține o listă de biblioteci externe de care depinde aplicația. Acum, în lista de dependențe există doar Zend Framework 2, dar în viitor, vom adăuga aici câteva dependențe: Doctrină, Twig și altele. După adăugarea unei noi dependențe, va fi suficient să executați comanda din consola:
și Compozitor descarcă bibliotecile necesare. Toate dependentele externe sunt adăugate în directorul furnizorului. acum putem vedea directoarele zendframework și compozitorii din el.
Documentație rădăcină
Rata de document a aplicației noastre nu este în rădăcina proiectului, ci în directorul public. Aici este localizat fișierul index.php - punctul de intrare pentru proiectul nostru și serverul web trebuie să fie configurat să funcționeze cu acest director.
Index.php îndeplinește mai multe sarcini importante, cele două cele mai interesante sunt conectarea bibliotecilor externe, încărcarea configurației aplicației și lansarea acesteia.
Pentru biblioteci externe executate init_autoloader.php fișier din rădăcina proiectului, care, la rândul său, determină furnizor / autoload.php și urmate de compozitor furnizor / compozitor de fișier generat automat / autoaload_real.php. În acest fișier sunt definite metodele de autoloading pentru bibliotecile externe încărcate de Compilator. Astfel, atunci când conectăm codul modulelor noastre sub formă de Zend \ View \ Model \ ViewModel, PHP va ști ce fișiere să caute în spațiul de nume dat.
Încarcă fișierele de configurare a aplicațiilor și o lansează. În timpul inițializării aplicației (apelând metoda Zend \ Mvc \ Application :: init ()), este creat un ServiceManager, un obiect cheie utilizat în multe părți ale aplicației. În mod implicit, ServiceManager creează un alt obiect cheie - EventManager. În viitor, atunci când vom crea modulele în setările lor, vom informa Service Manager ce alte obiecte ar trebui create pentru funcționarea modulului nostru.
Despre Managerul de servicii vom vorbi mai târziu, dar acum să aruncăm o privire mai atentă la directorul config. Acesta conține fișierul application.config.php. Returnează un matrice cu o configurație a aplicației care poate spune multe lucruri interesante.
Matricea modulelor conține o listă a modulelor incluse, acum avem doar un modul de aplicație, dar în viitor vor exista mai multe.
Matricea module_listener_options conține două elemente interesante: tablouri modul_paths și config_glob_paths.
Modulul_paths array spune unde să caute plug-in-uri, implicit în directoarele furnizorilor - dependențe externe și modul - vor exista module dezvoltate de noi pentru proiectul nostru.
Config_glob_paths conține măști de cale către fișiere de configurare a modulelor. Expresia regulată "config / autoload / .php" înseamnă că toate fișierele module_name..php, global.php, local.php vor fi încărcate din directorul config / autoload.
Astfel, în primul rând, încărcând setările din fișierul de configurare / application.config.php, apoi încărcând setările din fișier de configurare / autoload / .php și ultimele setări prestabilite încărcate la nivelul modulului (vom discuta acest lucru mai târziu).
În cazul în care config / Încărcare automată sunt două setări pentru fișierul de același modul: global și local (module_name.global.php și module_name.local.php), atunci primul pas este încărcat fișier global și local după el, adică, setările locale au prioritate față de cele globale.
fișiere local.php și * implicit .local.php .gitignore incluse în fișierul (dacă utilizați un alt sistem de control al versiunii, care au nevoie pentru a adăuga o excepție de mână), iar acestea ar trebui să fie utilizate numai pentru setările corespunzătoare numai mediul actual. Asta este, dacă aveți un proiect într-o formă sau alta rula pe mai multe platforme diferite: platforme de producție, testare și dezvoltare, cererea globală setări trebuie să stocheze datele relevante pentru toate aceste site-uri, și locale - sunt unice pentru fiecare site, de exemplu, , date pentru accesul la baza de date.
În plus față de global pentru întreaga aplicație de fișiere de configurare, fiecare dintre module poate avea propriul fișier de configurare. Astfel de fișiere de configurare a modulelor sunt încărcate în ordinea în care lista fișierelor active este definită în fișierul application.config.php. Astfel, dacă doriți să înlocuiți setările unui alt modul din modulul dvs., atunci modulul dvs. ar trebui să fie mai jos în această listă.
Ultimul director important și care nu a fost încă considerat este directorul modulelor. În acest director vor fi module dezvoltate de noi pentru aplicația noastră. Împreună cu ZendSkeletonApplication, este livrat un modul de aplicație, dar înainte de a studia structura acestuia, să analizăm ce este ServiceManager și de ce este necesar.
ServiceManager
întreprinderile înregistrate în ServisMenedzhere sau module.config.php default.conf fișier de configurare în secțiunea service_manager sau Module.php în getServiceConfig () metodă, se pare ca acest lucru (de exemplu, copiat din documentația):
Având configurația de mai sus a Managerului de servicii în oricare dintre controlorii noștri, putem apela codul ca:
și obiectul $ user_form va conține formularul corespunzător.
Acum este momentul să vă întoarceți la modulul de aplicație inclus în ZendSkeletonApplication.
Modul de aplicație
Arborele de directoare al acestui modul arată astfel:
Să începem cu Module.php. Acest fișier declară clasa Module cu 3 metode:
Codul metodei onBootstrap () din acest modul este responsabil pentru service-ul rutelor tipului de segment (despre tipurile de rute de mai jos).
Metoda getAutoloaderConfig () descrie nucleul cadrului unde să caute codul sursă al modulului:
În acest caz, acesta este directorul modules / Application / src / Application.
Metoda getConfig () returnează calea către fișierul de setări al modulului:
Acest fișier returnează un tablou cu setările care conțin următoarele date:
- Elementul matricei routerului este o matrice care conține lista rutelor deservite de modul și lista controlorilor pentru fiecare dintre rute.
- view_manager conține căile spre șabloanele care vor fi utilizate de aplicație și un număr de setări de șablon suplimentare.
- service_manager - o listă de obiecte care trebuie inițializate de Service Manager.
- o serie de alte setări.
În setările modulului de aplicație sunt definite două trasee:
Modulul Application conține un singur controler IndexController () cu o singură acțiune indexAction (), care returnează o pagină cu un mesaj de întâmpinare. Pentru a afișa această pagină, sunt utilizate șabloanele din directorul de vizualizare al modulului.
În acest sens, aș dori să închei prima parte a articolului. În al doilea și al treilea vom lucra la dezvoltarea modulului nostru mic și vom conecta câteva sisteme externe la sistem.
Articole similare
Trimiteți-le prietenilor: