Share
Cu oamenii care încep să realizeze potențialul WordPress ca fundație de aplicație, nu doar un sistem de management al conținutului sau o platformă de blogging, această serie se concentrează pe modul în care WordPress poate fi folosit pentru astfel de proiecte.
Unul dintre cele mai importante lucruri de remarcat este că WordPress nu este menit să fie soluția definitivă pentru construirea de aplicații web. De fapt, nu cred orice fundație sau cadru trebuie să fie soluție definitivă.
În schimb, avem o serie de opțiuni diferite, toate oferind situații mai bune decât altele, iar WordPress nu este diferit. De-a lungul acestei serii, vom continua să aruncăm o privire asupra modului în care aplicațiile web pot fi construite cu WordPress și care sunt situațiile care se pretează cel mai bine fundației. Cu toate acestea, trebuie să continuăm discuția despre modul în care funcționează WordPress, astfel încât să putem începe să vorbim despre cum să construiți aplicații în plus.
În articolul precedent, am discutat despre numărul de cadre care oferă o abordare MVC pentru dezvoltare, dar ne-am uitat și la modelul WordPress bazat pe evenimente. În acest post, vom examina mai profund paradigma condusă de eveniment pe care WordPress o folosește și de ce este important acest lucru.
Adevărul este că mulți oameni sunt familiarizați cu această paradigmă, ei pur și simplu nu sunt familiarizați cu convențiile de numire. Până la sfârșitul acestui articol, ar trebui să avem o înțelegere clară în ceea ce privește programarea bazată pe evenimente, modul în care funcționează, modul în care este implementat în WordPress și cum trebuie să ne gândim la acest lucru când vine de la alte modele cum ar fi Model View -Controlor.
În ultimul post, am rezumat programarea bazată pe evenimente, cu următoarea idee:
În schimb, programarea bazată pe evenimente se îndepărtează de premisa că "ceva așa cum sa întâmplat". De aici și numele acţiuni în WordPress lingo (desigur, avem filtre, dar le voi acoperi pe moment).
Și asta este bine pentru o definiție de lucru a evenimentelor, în special la un nivel înalt. Cu toate acestea, dacă doriți să examinați mai atent cum arată acest lucru dintr-un punct de vedere practic - și anume, de la modul în care WordPress îl implementează - atunci probabil că cel mai bun lucru pe care îl puteți face este să înțelegeți evenimente.
Dar chiar mai mult decât atât, este important să înțelegem ciclul de viață al paginilor WordPress, unde se întâmplă evenimentele și cum putem - ca dezvoltatori - să ne conecteze pentru a îndeplini o anumită sarcină.
Așa cum am menționat deja, în programarea bazată pe evenimente, ideea evenimentelor este pur și simplu aceea ceva sa întâmplat. Continuăm să re-iterăm asta, dar ce înseamnă cu adevărat asta?
În contextul încărcării unei singure pagini, există o serie de lucruri care apar:
Toate acestea pot fi considerate evenimente, dar fiecare dintre acestea este alcătuită din propriul set de evenimente mai mici - adică puteți obține într-adevăr detaliate cu privire la momentul în care se întâmplă ceva.
Luați, de exemplu, ideea de a face o solicitare tipică, orientată spre public, pentru o pagină alimentată cu WordPress. Dacă vă uitați la documentul Codex asociat, veți observa că există aproximativ 50 de acțiuni care apar și acest lucru se întâmplă nu include acțiuni specifice postului sau paginii.
Fiecare dintre aceste acțiuni poate fi considerat un eveniment, iar în lumea programării determinate de eveniment, evenimentele sunt de obicei expuse astfel încât să ne permită să le cuprindem și să manipulăm informațiile înainte de a fi redate clientului.
De aici numele pentru cârlige.
Desigur, în WordPress, cârligele vin în două varietăți: acțiuni și filtre. Deși această serie nu este despre un tutorial solid pe fiecare dintre acestea, aceasta este important să recunoaștem diferența dintre ele în ceea ce privește lucrul cu WordPress.
Acțiunile sunt un tip de cârlig care înseamnă că sa întâmplat ceva și cand acea ceva apare, avem capacitatea de a ne înregistra propriile funcționalități, astfel încât să putem injecta propriul cod (sau chiar să împiedicăm anumite lucruri să se întâmple).
Așa cum am rezumat în seria mea despre Acțiuni și filtre:
Acțiunile sunt evenimente din ciclul de viață al paginii WordPress atunci când au apărut anumite lucruri - anumite resurse sunt încărcate, anumite facilități sunt disponibile și, în funcție de cât de devreme a avut loc acțiunea, unele lucruri trebuie încă încărcate.
Este important să înțelegeți acțiunile disponibile, astfel încât să știți când este cel mai bun moment să vă conectați la un anumit eveniment, astfel încât să nu împiedicați performanța paginii, să mângâieți eventual alte date care vin în aval sau să vă fie în mod corespunzător manipularea informațiilor la momentul și locul potrivit.
Filtrele, pe de altă parte, un tip de cârlig care ne permit să recepționăm o anumită bucată de date, să o manipulăm și apoi să o întoarcem în WordPress înainte de ao redirecționa către browser.
De exemplu, dacă te uiți la continutul filtru, atunci veți observa că dacă ați cupla o funcție în această acțiune particulară, funcția dvs. va primi conținutul. Aceasta înseamnă că veți putea să manipulați conținutul introducând informații în el, înlăturând informații din el sau ceva similar, înainte de a le trimite înapoi la WordPress pentru a le oferi browserului.
În mod similar, am rezumat filtre în seria mea despre acțiuni și filtre, după cum urmează:
Filtrele sunt funcții pe care WordPress le transmite prin anumite puncte din ciclul de viață al paginilor. Aceștia sunt responsabili în primul rând pentru interceptarea, gestionarea și returnarea datelor înainte de a le trimite la browser sau de a salva datele din browser în baza de date.
Deci, cu toate acestea, acțiunile și filtrele sunt ambii tipuri de evenimente care apar în cadrul ciclului de viață WordPress care ne permit cârlig în ele și introduceți propriul cod pentru execuție înainte de al redacta browserului.
Pe scurt, termenul "cârlige" este un termen general care se referă atât la acțiuni, cât și la filtre, fiecare dintre acestea servind unui scop diferit.
Acum, unul dintre cele mai obișnuite lucruri pe care le-am văzut de la oameni care provin dintr-un mediu diferit, cum ar fi Rails, CakePHP, ASP.NET sau alte cadre MVC, este cum să-ți hărțiți modelul conceptual al MVC la evenimentul- condus de WordPress.
Prin asta, vreau să spun că încearcă să găsească analogii cu modelele, vederile și controlorii în paradigma condusă de evenimente. De exemplu, unii pot încerca să facă următoarele:
În acest scop, vă recomand să încercați să evitați să vă gândiți la WordPress în contextul unui alt model. Are modelul propriu. Gândiți-vă la acești termeni.
Pe scurt, a veni la WordPress dintr-un alt cadru care utilizează un alt model de design sau altă paradigmă este bine, dar nu este vorba de a face WordPress să se potrivească cu experiența anterioară.
Nu puteți să modernizați un model de design într-altul și să vă așteptați să obțineți rezultate de înaltă calitate.
Software-ul nu funcționează așa.
În schimb, așa cum faceți și cu alte cadre, voi trebuie sa gândiți-vă la modul în care WordPress funcționează pentru a construi în mod corespunzător lucrurile pe - și pentru - WordPress. Mai târziu în serie, vom analiza de ce WordPress face o opțiune solidă pentru aplicațiile web, dar înainte de asta cred că este important să înțelegem modelul pe care WordPress îl implementează și cum să profite cât mai bine de acesta.
În următoarea postare, vom examina câteva exemple cu privire la modul în care ne putem conecta la evenimentele oferite de WordPress. Acestea vor fi foarte introductivi și cei mai experimentați dezvoltatori WordPress probabil vor cunoaște deja multe dintre ele; cu toate acestea, acesta va oferi un set solid de exemple cu privire la modul în care acțiunile și filtrele - și, astfel, evenimentele - lucrează în WordPress.
După aceea, vom continua discuția noastră cu privire la caracteristicile și facilitățile oferite de WordPress pentru construirea de aplicații web.
Accentsconagua