Az írás egy modul DLE - részletes használati
Ez a cikk leírja, hogyan kell igazán részletesen elemzik létrehozásának folyamatát egy egyszerű modult DLE gyorsítótárazással és saját sablonokat. Nézzük az első modul nélkül a sablont, majd kiegészíti azt saját sablonokat. Az eredmény a cikk lenne működőképes anélkül admin modul, az úgynevezett bárhol az oldalon keresztül a connection string.
Miért nem használja DLE_API
Ez egyszerű - ez nagyon görbe dolog, hogy nem alakul ki a sokat (8.2 verzió, mint az írás, az aktuális verzió a motor - a 10.0 és az előző verzió csak fix bug a lehetetlenségét regisztráció a felhasználó az API segítségével, nincsenek módosítások nem végzett).
Használata dle_api jelentősen növeli a fogyasztást a memória nagyon, nagyon nem jó.
A leírt módszerek dle_api eltérnek eredeti funkciót.
Általános tanács: Ha szüksége van néhány módszer, vagy a funkció dle_api - csak másolja a modult.
Talán a szerény fejlesztések tart egy sor módszerek és funkciók, amelyek felhasználhatók a jövőben, de ez a téma egy másik cikk.
Mielőtt írásban minden modul (kivéve azokat a fájlokat, amelyek felelősek ajax), meg kell okvetlenül, a kezdet kezdetén, hogy regisztráljon egy sorban:
Ez nem teszi lehetővé a felhasználó számára, hogy alkalmazni kell a plug-in fájlokat közvetlenül, ami azt jelenti, nem tud közvetíteni a saját paramétereit, és a modul csapkod az oldalon az ebben a modulban. Azt hiszem, fontos ez a pont nem lehet túlbecsülni, de mégis, gyakran megbotlik a hiánya egy ilyen szerkezet a modul kódját.
Konfiguráció és gyorsítótár
Úgy döntött, hogy megáll ezen a ponton részletesen, mert ez az egyik leggyakrabban feltett kérdés, ha valaki úgy döntött, hogy írjon egy modult.
Konfigurációs modul legjobb eredménye a tömb - ez adja a lehetőséget, hogy hozzon létre egy hibamentes cache minden modulhoz hívást egy másik sor konfiguráció, ebben az esetben minden felhasználó számára.
Elmondjuk, miért. Tegyük fel, hogy írt egy modult, akkor cache, és az átmeneti időszak létrehozása a cache a következő:
ahol:
- $ Var1 $ var2 $ VAR3 $ var4 -... változók modult.
- $ MyModule - szöveget, hogy beiratkozik a cache.
és létrehozta a cache ez:
Így nem kell mászni a kód elveszett, minden fog történni automatikusan.
Előtagot és utótagot cache - ez biztosítja az automatikus tisztítási cache, valamint (adott esetben), hogy hozzon létre külön cache a különböző felhasználói csoportok számára.
Az érthetőség kedvéért fogom magyarázni, nézd meg a képet:
Tehát ebben az esetben levéltárnak szükséges prefix Cache modult kell állítani csak akkor hozzáadni vagy eltávolítani hírek (ez csak tetszik, akkor használja a naptár és RSS). Kód config és hozzon létre egy cache nem adja ide, így nem terhelik feleslegesen a történetet, az összes modul kódját megtekinthető itt.
Szöveg cache - ez az eredménye a modul, amely rögzítésre kerül a cache, akkor ez egyszerű.
ID cache vagy név - itt a legjobb, hogy adja át a változó $ cacheName, amiről azt fentebb írt és a változó $ config [ „skin”] - ezt annak érdekében, hogy a különböző cache különböző weboldal sablonokat.
Prefix cache - lehet, hogy két érték, igaz vagy hamis, ha elfogadják, hogy igaz, az egyes felhasználói csoportok létrehoz egy cache fájl, akkor van szükség, amennyiben a különböző felhasználói csoportok kell megjeleníteni a különböző tartalmak.
Az univerzális üres cache modul nélkül sablon
Mivel a fent leírt, mi is létrehozhatunk egy egyszerű sablont egy modul, amely használni fogja a cache, de nem fogja használni a munkájuk mintát. Csak 15 sornyi kódot!
Elég egyszerű, nem igaz?
Lekérdezi az adatbázist és ellenőrzések
A legegyszerűbb teszt - azzal a feltétellel, ha mást:
azaz egyszerűen ellenőrizheti, hogy áthatol a connection string változót, ha elfogadják (azaz nem üres) - fut értéke a $ db-> safesql - ez megvéd minket a „rossz” felhasználói bejelentkezések, mint változó egészül ki a kérést az adatbázishoz.
$ CatID változtatható szűrő nem szükséges, mert a kivéve ez nem a szám nem kérdez buta, hogy írjon valami mást a connection string. Azonban meg kell egy alapértelmezett érték, ezért az ellenőrzést szükség, és akkor tudjuk regisztrálni közvetlenül a config modul:
A változók érteni, lekérdezheti az adatbázist.
Ebben az esetben csak akkor kell egy értéket az adatbázisból, és használja a teljes lekérdezést, majd szétszedni - nincs értelme, így fogjuk használni super_query módszer, visszatér az alapértelmezett egydimenziós tömböt.
A végső kérés lesz:
ahol:
$ MyConfig [ 'CatID'] - id ktegorii.
$ MyConfig [ 'username'] - a felhasználó nevét.
előírják, hibakeresés alábbi kódot:
modul hívás a következő:
Ha a változók helyes - az eredmény egy sor hibakeresési adatok egyetlen elem száma
Most akkor jeleníti meg az eredményt a rendes:
Itt meg kell jegyezni, hogy ha a cache lesz írva egy lábujj - DLE akkor nem „számít cache”, és hozzon létre egy újat, így meg kell, hogy írjon valami más, mint nulla.
a modul kapott kód így néz ki:
Összesen 20 sornyi kódot - és készülj, hogy megoldja a problémát.
Modul kód jól működik, és fel lehet használni a valós projekt, de a csökkentett promóciós kód, hogy megismerjék a helyes elveit írásban modulok DLE.
Ennél a végén, de a fenti megígértem, hogy bemutassák a kódot a modul segítségével a saját sablont.
Univerzális felkészülés modul saját cache és egy sablont
Általában ugyanaz az egység, hogy írtunk nélkül a sablon nagyon könnyen húzza a „Template” modult, de a mi esetünkben ez nincs értelme, mert a modul kijelzi csak egy számjegyet. Egyéni sablon modul legjobban használható, ha a megjeleníteni kívánt több értéket különböző design különböző területein a helyszínen.
$ C = new stdClass;
$ C-> INCPATH = könyvtárnév (__ FILE __) '/' .;
chdir ($ C-> INCPATH);