Acest articol descrie modul de detaliere a procesului de creare a unui modul simplu pentru DLE cu cache și propriile șabloane. În primul rând, vom analiza modulul fără un șablon și apoi îl vom adăuga cu propriul nostru șablon. Rezultatul articolului va fi un modul funcțional fără admin, apelat oriunde pe site prin șirul de conectare.
De ce nu folosiți DLE_API
Este simplu - este foarte curba de lucru care nu se dezvolta la fel de mult de la versiunea 8.2 (ca din acest scris, versiunea curentă a motorului - 10.0 și în comparație cu versiunea anterioară fixată doar un bug cu imposibilitatea înregistrării unui utilizator prin API-ul, nici o modificare nu sunt efectuate).
Utilizarea lui_api crește semnificativ consumul de memorie RAM, ceea ce este complet, deloc bine.
Metodele descrise în dle_api diferă de funcția originală.
Sfat general: dacă aveți nevoie de o metodă sau o funcție de la dle_api - copiați-o în modulul dvs.
Poate că evoluțiile mele modeste vor fi suficiente pentru un set de metode și funcții care pot fi folosite în viitor, dar acesta este un subiect pentru un articol separat.
Înainte de a scrie orice modul (cu excepția fișierelor care sunt responsabile de ajax), trebuie, fără întârziere, de la început să scrieți o linie:
Acest lucru va împiedica utilizatorul să acceseze direct fișierul modulului, ceea ce înseamnă că acesta nu va putea să transfere parametrii proprii în modul și să hackeze site-ul prin acest modul. Cred că importanța acestui moment este dificil de supraestimat, dar cu toate acestea, mă confrunt adesea cu lipsa unui astfel de design în codul modulului.
Configurare și cache
Am decis să mă ocup de acest punct în detaliu, tk. aceasta este una dintre cele mai frecvente întrebări adresate dacă o persoană decide să-și scrie propriul modul.
Configurația modulului este scrisă cel mai bine într-o matrice - aceasta va face posibilă crearea unei memorii cache fără probleme pentru fiecare apel al modulului cu un set diferit de configurații, în cazurile noastre pentru fiecare utilizator.
Voi explica de ce. Să presupunem că am scris un modul, este stocat în cache, iar timpul de creare a cache-ului este după cum urmează:
în cazul în care:
- $ var1. $ var2. $ var3. $ var4 - variabile de modul.
- $ myModule - text care ar trebui să fie stocat în cache.
iar linia de creare a cache-ului va fi:
Deci nu trebuie să urcăm deloc în acest cod, totul se va întâmpla automat.
Utilizați prefixele și sufixele memoriei cache - aceasta va asigura că cache-ul este șters automat și, de asemenea, permite (dacă este necesar) crearea de cache-uri separate pentru diferite grupuri de utilizatori.
Pentru claritate, să aruncăm o privire la imagine:
Deci, în cazurile noastre avem nevoie de arhivele prefixelor. cache-ul modulului trebuie să fie resetat numai când se adaugă sau se elimină știri (mi-a plăcut, puteți utiliza atât calendar cât și rss). Codul de creare a config-urilor și a cache-urilor nu va fi dat în așa fel încât să nu se confundă cu articolul, tot codul modulului poate fi vizualizat mai jos.
Textul cache-ului este rezultatul lucrării modulului, care va fi scris în cache, totul este simplu.
cache ID-ul sau numele - aici este cel mai bine să treacă cacheName variabila $, despre care a fost scris mai sus, iar $ config variabilă [ „piele“] - acest lucru pentru a avea cache-uri diferite pentru diferite site-ul șabloane.
cache Prefixul - poate lua două valori, adevărate sau false, în cazul în care a trecut la true, pentru fiecare grup de utilizatori va crea un fișier cache, este necesar, în cazul în care diferite grupuri de utilizatori au nevoie pentru a afișa conținut diferit.
Blank universal pentru un modul cu memorie cache, fără șablon
Având în vedere toate cele de mai sus, putem crea un simplu spațiu pentru modulul care va utiliza memoria cache, dar nu va folosi șablonul în activitatea sa. Numai 15 linii de cod!
Este destul de simplu, nu?
Cerere către DB și validare
Cel mai simplu test este dacă este altul:
și anume verificăm dacă pur și simplu transmise prin variabila șir de conexiune, în cazul în care a trecut (de exemplu, nu este gol) - pentru a rula valoarea prin $ DB> safesql - ne va proteja de „greșit“ conectările de utilizator, ca Valoarea variabilei va fi inserată în interogare în baza de date.
Nu este necesar să filtrați variabila $ catId, deoarece cu excepția cazului în care un număr nu specifică și este greu să scrie altceva în șirul de conectare. Cu toate acestea, trebuie să existe o valoare implicită, astfel că verificarea este necesară și o putem scrie direct în fișierul config:
Cu variabilele sortate, acum interogarea este în baza de date.
În cazurile noastre, aveți nevoie de o singură valoare din baza de date și folosiți o interogare completă și atunci nu are sens, deci vom folosi metoda super_query, care implicit returnează o matrice unidimensională.
Interogarea noastră finală va fi:
în cazul în care:
$ myConfig ['catId'] - id al categoriei.
$ myConfig ['userName'] este numele de utilizator.
mai jos vom scrie codul de depanare:
Apelați modulul astfel:
Dacă variabilele sunt specificate corect, rezultatul depanării este o matrice cu date constând dintr-un element de numărare
Acum puteți tipări rezultatul în mod normal:
Aici trebuie remarcat faptul că, în cazul cache-ul va fi scris un singur deget de la picior - DLE nu va „conta cache“ și de a crea unul nou, deci trebuie să scrie altceva decât zero.
Codul final al modulului nostru va fi:
Doar 20 de linii de cod - și avem o soluție gata la o anumită problemă.
Codul modulului funcționează complet și poate fi folosit într-un proiect real, dar acest cod este dat să vă familiarizați cu principiile corect de scris module pentru DLE.
Acest lucru ar putea fi finalizat, dar mai sus am promis să arat codul modulului folosind propriul meu șablon.
Blank universal pentru un modul cu cache și propriul șablon
În general, același modul pe care l-am scris fără un șablon este destul de ușor de tras și de modulul "șablon", dar în cazurile noastre acest lucru nu are sens, deoarece modulul emite o singură cifră. Șablonul propriu în modul este mai bine folosit atunci când este necesar să se afișeze mai multe valori cu design diferit în diferite locuri ale site-ului.
$ C = noul stdClass;
$ C-> INCPATH = dirname (__FILE __). '/';
chdir ($ C-> INCPATH);
Ti-a placut updateul DataLife Engine 11.2?
Articole similare
-
Cum sa faci o masa de plasticina pentru papusi Barbie si instructiuni de mare monstru cu fotografie
-
Tablet-navigator cum să conectați un modul extern USB-gps, un receptor pentru tabletă
Trimiteți-le prietenilor: