Astăzi am optimizat activitatea unui site și vreau să ofer câteva sfaturi care pot fi utile pentru mulți programatori novici, în special cei care se află la nivelul dezvoltării la nivel de tag-uri MODX.
Apropo, voi observa imediat că acesta este un site de cărți de vizită, iar toate paginile sunt stocate în memoria cache, cu excepția blocurilor individuale.
Deci, cel mai important minus pe care l-am întâlnit. În majoritatea șabloanelor, conținutul paginii a fost transmis printr-o bucată personalizată, în care eticheta [[* content]] a fost deja înregistrată. Iată lista completă a acestei fragmente:
Aici vă propun să acordați atenție construcției tipului [[* parent: is = `240`: then =` ... Care este problema aici? Problema este că parserul MODX nu funcționează ca, de exemplu, interpretul php. În mod logic, aceasta ar trebui să fie următoarea: dacă părintele documentului curent este 240, atunci se execută blocul Then. În mod logic Da, dar în practică Nu Voi arăta un exemplu simplu despre cum sunt procesate condițiile pe php pentru a arăta ce nu se întâmplă. Iată un cod simplu:
Deci, în acest exemplu, dacă părintele nu este 240, funcția time () nu va fi executată în principiu. La parsarea MODX, conținutul blocului va fi executat în orice caz, pur și simplu rezultatul va fi afișat pe pagină sau nu, determinând adevărul condiției.
În acest caz, indiferent de condiție, parserul MODX a executat complet blocul Then și numai apoi, în funcție de condiție, decide dacă va ieși sau nu rezultatul acestui bloc. Adică, indiferent de documentul părinte, toate blocurile din această bucată vor fi executate. Între timp, există patru dintre aceste blocuri, dintre care două sunt fragmentul UNEXPECT getPage. Aceasta înseamnă că, chiar dacă pagina este deja stocată în memoria cache, MODX va procesa aceste fragmente de fiecare dată când accesează, deoarece acestea nu sunt cacheate. Ca rezultat: 5-10 secunde pentru a genera codul paginii cache pentru o secunda cu logica corectata.
Aici am ajuns la modul de a prescrie în mod corespunzător astfel de lucruri. Sfatul meu: folosiți mai puține bucăți, mai multe fragmente. În ciuda faptului că bucăți percepute psihologic elemente mai simple (cum le place ca HTML, mai degrabă decât PHP executabil), cu toate acestea utilizarea lor impune costuri suplimentare ca o sarcină suplimentară pe parser. În plus, așa cum am scris aici. în bucăți gestionați elemente cache numai la nivelul documentului curent, nu la nivelul întregului site. Prin urmare, încercați să urmați regula: orice logică în fragmente, design în bucăți.
Cum ar fi mai corect să implementăm logica? 1. Creați o bucată pe care o avem ca șablon pentru afișarea rezultatului fragmentului.
Notă: există aici doi substituenți: pre_content și post_content. Când creați bucăți, dacă nu sunteți sigur că variabilele vor fi transmise tuturor înlocuitorilor, doar în cazul în care creați Parametri goi pentru această bucată. În cazul nostru, acestea sunt parametrii pre_content și post_content. Nu știu cât de mult a fost fixat acum, dar mai devreme parserul a încercat să "găsească" o variabilă de 10 ori înainte de a mesteca bucata.
2. Creați un fragment.
În acest fragment, nu am înregistrat cache-ul suplimentar, dar pentru noi acum principalul lucru este că blocurile din interiorul condițiilor vor fi îndeplinite numai atunci când condiția este îndeplinită. Din acest motiv, în practică am redus foarte mult timpul pentru generarea paginii. Ca rezultat, codul nu a devenit confuz, dar performanța a crescut dramatic.
Și în cele din urmă, sfat: nu păstrați o mulțime de cod în șabloane. Pe multe site-uri, paginile au același antet și subsol pe întregul site (de regulă, numai pagina principală poate diferi substanțial). Așadar, creați o bucată de antet și subsol comun și le încărcați în fiecare șablon, astfel încât să nu trebuiască să le schimbați pretutindeni dacă trebuie să schimbați un bloc. Și apoi imaginați câte mișcări trebuie să faceți pentru a schimba designul și logica pe site, pe care 15 bucăți sunt astfel de șabloane:
Adică înțelegi ce vreau să spun?
Cred că înțeleg. 99% sold de acest lucru: (!? Eu vorbesc despre [[If) indiferent de starea dumneavoastră la nivelul șablon, bucăți [[$ fullTemplate]] și [[$ mobileTemplate]] vor fi îndeplinite în orice caz. Acestea sunt caracteristicile parserului MODX. Acesta nu este pur php pentru tine, în cazul în care dacă condiția if () nu reușește, atunci nu se va face nimic în interiorul ei. Și aici Dacă - nu este chiar o funcție, ci pur și simplu o etichetă (dacă vorbim despre șablonare). Ca urmare, el fie iese, fie nu scoate rezultatul. Dar rezultatul din interior va fi, adică, etichetele interne vor fi elaborate.
Acesta este unul dintre motivele grave pentru care folosim modxSmarty și nu modelul nativ MODX. La nivelul Smarty, acest lucru ar fi cazul:
Aici va fi clar dacă cineva este împlinit sau altul.
Dacă doriți să o faceți pe MODX-e pur, atunci nu fragmentați Dacă trebuie să apelați și să scrieți propriul fragment, care va apela în mod clar una sau cealaltă bucată. returnați $ modx-> getChunk ($ chunkName);
Articole similare
-
Este necesară licențierea și certificarea tehnicii aviației mici și a sportului pentru aviație mică
-
Trebuie să mergeți în centrul competiției pentru a înțelege ceea ce sunteți în picioare pentru "
Trimiteți-le prietenilor: