Hogyan ne programozzon modxen?

Ma optimalizáltam egy webhely munkáját, és szeretnék néhány olyan tippet adni, amelyek hasznosak lehetnek sok kezdő programozó számára, különösen azok számára, akik a MODX szintjén a fejlesztés szintjén vannak.

Egyébként azonnal tudomásul veszem, hogy ez egy névjegykártya-webhely, és az összes oldalt tárolják, kivéve az egyes blokkokat.

Tehát a legfontosabb mínusz, amivel találkoztam. A legtöbb sablonban az oldal tartalma egy egyedi csomóponthoz érkezett, amelyben a [[* content]] címke már regisztrálva volt. Itt található a teljes lista:

Itt azt javasoljuk, hogy fordítsanak figyelmet a [[* parent: is = `240` típus] építésére: akkor =` ... Mi a probléma itt? A probléma az, hogy a MODX elemző nem működik, például a php-tolmácsnak. Logikusan ez a következő: ha az aktuális dokumentum szülője 240, akkor a Then blokk végrehajtódik. Logikusan Igen, de a gyakorlatban nem. Megmutatom egy egyszerű példát arra, hogy miként dolgozzák fel a php állapotát annak megmutatására, hogy mi nem történik meg. Íme egy egyszerű kód:

Tehát ebben a példában, ha a szülő nem 240, akkor az idő () függvény nem hajtható végre elvben. A MODX elemzésénél a blokk tartalma minden esetben végrehajtásra kerül, egyszerűen az eredmény jelenik meg az oldalon, vagy sem, meghatározza az állapot igazságát.

Ebben az esetben, attól függetlenül, hogy a MODX elemző teljesen végrehajtotta a Then blokkot, és csak akkor, az állapot alapján dönt arról, hogy kiadja-e a blokk eredményét vagy sem. Azaz, függetlenül attól, hogy melyik szülő a dokumentum, a blokk összes blokkja végrehajtásra kerül. Időközben ezen blokkok közül négy van, ezek közül kettő az UNEXPECT getPage kódrészlet. Ez azt jelenti, hogy ha az oldalt már gyorsítótárba helyezte, a MODX feldolgozza ezeket a kódrészleteket minden alkalommal, amikor elérte azt, mert nem tárolt. Ennek eredményeképpen: 5-10 másodperc, hogy a gyorsítótáras oldal kódját egy másodpercig javítsa a korrigált logikával.

Itt juthatunk el, hogyan kell megfelelően leírni ezeket a dolgokat. A tanácsom: kevésbé használható darabok, több kivágás. Annak ellenére, hogy a darabokat pszichológiailag egyszerűbb elemek érzékelik (mivel olyanok, mint a HTML, nem pedig a php végrehajthatóak), mégis használatuk további költségeket ró, hiszen az elemzőt is betöltötték. Plusz, ahogy írtam itt. darabokban az elemek gyorsítótárát csak az aktuális dokumentum szintjén szabályozza, és nem az egész webhely szintjén. Ezért próbálja meg követni a szabályt: a logikai részleteket a részletekben, a darabokban történő tervezést.

Hogyan lenne helyesebb a logika megvalósítása? 1. Hozzon létre egy darabot, amelyet sablonként adunk meg a kódrészlet eredményének megjelenítéséhez.

Megjegyzés: itt két helyőrző található: pre_content és post_content. Darabok létrehozásakor, ha nem biztos benne, hogy a változók átkerülnek minden helyőrző helyére, csak abban az esetben, ha üres paramétereket hoz létre ehhez a darabhoz. Esetünkben ezek a paraméterek pre_content és post_content. Nem tudom, mennyire rendezett, de korábban az elemző 10 alkalommal próbálta "találni" egy változót, mielőtt rágta a darabot.

2. Hozzon létre egy kódrészletet.

Ebben a részletben nem regisztráltuk a további gyorsítótárazást, de most számunkra a legfontosabb az, hogy a feltételeknek megfelelő blokkok csak akkor teljesülnek, ha a feltétel teljesül. Emiatt a gyakorlatban nagyon csökkentettük az oldal generálásának idejét. Ennek eredményeképpen a kód nem zavaró, de a teljesítmény drámaian megnőtt.

És végül a tipp: ne tárolj sok kódot a sablonokban. Sok webhelyen az oldalak ugyanazon fejléccel és alagsorral rendelkeznek az egész webhelyen (szabály szerint csak a főoldal lényegesen eltérhet). Tehát hozzon létre egy közös fejlécet és láblécet, és töltsön be őket minden sablonba, így nem kell mindenhol megváltoztatnia, ha meg kell változtatnia egy blokkot. És akkor képzelje el, hogy hány mozdulatot kell tennie ahhoz, hogy megváltoztassa a tervezést és a logikát a webhelyen, amelyen 15 darab ilyen sablon:

Vagyis érted, hogy mit értek?

Azt hiszem, értem. Az elrendezés 99% -a: attól függetlenül, hogy milyen állapotban van a sablonszinten (beszéltem [[? Ha?], A Chunks [[$ fullTemplate]] és a [[$ mobileTemplate] minden esetben kidolgozható. Ezek a MODX-parser jellemzői. Ez nem tiszta php az Ön számára, ahol ha az if () feltétel sikertelen, semmi sem fog végrehajtani belül. És itt Ha - ez még egy funkció sem, csak egy címke (ha sablonról beszélünk). Ennek eredményeképpen, vagy kimeneti, vagy nem adja ki az eredményt. De az eredmény mindenképpen megtörténik, vagyis a belső címkék kidolgozásra kerülnek.

Ez az egyik komoly oka annak, hogy miért használjuk a modxSmarty-ot, és nem a natív MODX sablont. A Smarty szinten ez a helyzet:

Itt lesz világos, hogy teljesült-e vagy sem.

Ha tiszta MODX-e-et akarsz csinálni, akkor ne töltsd le a kódrészletet Ha fel kell hívnod, és be kell írnod ​​a saját kódrészletedet, amely egyértelműen felhívja az egyiket vagy a másik darabot. vissza $ modx-> getChunk ($ chunkName);

Kapcsolódó cikkek