Тази статия описва как наистина да се анализира в детайли процеса на създаване на един прост модул за DLE с кеширане и свои собствени шаблони. Нека разгледаме първия модул без шаблон, а след това го допълнят със собствените си шаблони. Резултатът на статията ще бъде работещ без администратор модул, наречен навсякъде в сайта чрез низ връзка.
Защо не се използва DLE_API
Толкова е просто - това е много крива на нещо, което не се развива толкова, от версия 8.2 (като на това писание, текущата версия на двигателя - 10.0 и в сравнение с предишната версия само фиксира бъг с невъзможността за регистриране на потребител чрез API, никакви промени не се извършват).
Използването dle_api значително не се увеличава консумацията на памет, която наистина, наистина добре.
Методите, описани в dle_api различават с оригиналната функционалност.
Общи съвети: Ако имате нужда от някой метод или функцията на dle_api - просто го копирате в модул.
Може би моите скромни развитие ще продължи за набор от методи и функции, които могат да бъдат използвани в бъдеще, но това е тема за друга статия.
Преди да пишете модул (с изключение на файлове, които са отговорни за Аякс), трябва да се без да се провалят, в самото начало да се регистрират на един ред:
Това не позволява на потребителя да се прилага по отношение на плъг-ин файлове директно, което означава, че не може да изрази собствените си параметри в модула и хакна сайта чрез този модул. Мисля, че е важно този етап не може да се надценява, но все пак, аз често се препъват в липсата на такава структура в кода за модул.
Конфигурация и кеширане
Реших да се спре на този етап в подробности, тъй като тя е една от най-често задаваният въпрос, ако човек реши да напише модул.
Конфигурация модул най-добрия рекорд в масива - това ще даде възможност да се създаде безпроблемно кеш за всеки модул разговор с различен набор от конфигурацията, в този случай, за всеки потребител.
Нека обясня защо. Да предположим, че е написал модул, той се кешира и периода на създаването на кеш паметта е както следва:
когато:
- $ Var1 $ var2 $ var3 $ var4 -... Променливи модул.
- $ MyModule - текст, за да се запишат в кеша.
и създаването на кеш линия е тази:
По този начин, ние не трябва да се изкачи в този код винаги, всичко ще стане автоматично.
Използвайте представки и наставки кеш - това ще осигури автоматично почистване на кеша, както и даде възможност (ако е необходимо), за да създадете отделни кеш за различни групи потребители.
За по-голяма яснота, ще обясня, погледнете на снимката:
Така че в този случай, ако е необходимо архиви префикс Cache модул трябва да се нулира само когато добавяте или премахвате новини (тя просто ми харесва това, можете да използвате календар и RSS). Код довереник и създаване на кеша няма да даде тук, за да не се претрупва темата, на всички кодът за модул може да се разглежда по-долу.
Текст кеш - е резултат от модула, които ще бъдат записани в кеша, а след това е просто.
ID кеш или име - тук е най-добре да се премине на променливата $ cacheName, за които е написано по-горе, а променливата $ довереник [ 'кожа'] - това, за да има различни кеш за различни уебсайт шаблони.
Префикс кеш - може да отнеме две стойности, вярно или невярно, ако бъде приет, за да е истина, за всяка група ще създаде потребителски кеш файл, че е необходимо, ако различните групи потребители трябва да се покаже различно съдържание.
Универсалният празно за кеш модул без шаблон
Като се има предвид изложеното по-горе писмени, ние можем да създадем един прост шаблон за модул, който ще използва кеш паметта, но няма да се използва в работата си модел. Само на 15 реда код!
Доста е просто, нали?
Сверки с базата данни и проверки
Най-прост тест - условието, ако друго:
т.е. ние просто се провери дали се предава чрез променливата на низа за свързване, ако бъде приет (т.е. не е празна) - да се изпълнява своята стойност чрез $ db-> safesql - това ще ни предпази от "погрешната" потребителски влизания, като променлива се вмъква в искането до базата данни.
$ CatID променлива филтър не е необходимо, понеже освен това прави фигура не пита глупаво да пиша нещо друго в низа за връзка. Въпреки това, той трябва да бъде за стойност по подразбиране, така че е необходима проверка, и то можем да се регистрирате директно в модула за довереник:
С променливи разбрани, сега сверки с базата данни.
В този случай, трябва само една стойност от базата данни и да използват пълния заявката и след това да го разглобите - няма смисъл, така че ние ще използваме метод super_query, той се връща по подразбиране едномерен масив.
Крайната ни запитване ще бъде:
когато:
$ MyConfig [ 'CatID'] - ID ktegorii.
$ MyConfig [ 'потребителско име'] - името на потребителя.
предписват отстраняване на грешки кода по-долу:
модул повикване е както следва:
Ако променливите са верни - резултатът е масив от данни за отстраняване на грешки, брой единичен елемент
Сега можете да видите резултата от нормалното:
Тук трябва да се отбележи, че ако кеша ще бъде написан един пръст - това няма да DLE "брои кеш" и да се създаде нова, така че трябва да напиша нещо различно от нула.
нашият модул резултат код изглежда така:
Общо 20 реда код - и се пригответе за решаване на конкретен проблем.
Модул код работи добре и може да се използва в реален проект, но намалява промоционалния код, за да се запознаят с принципите на правилните модули за писане за DLE.
По това може да свърши, но по-горе съм обещал да покаже кода на модула с помощта на собствения си шаблон.
Универсален препарат за модул със собствен кеш и шаблон
В общи линии, същата единица, която сме написали без шаблона е доста лесно да плъзгате и модул "Шаблон", но в нашия случай това няма смисъл, защото модул показва само една цифра. Персонализирана шаблон модул се използва най-добре, когато искате да се покаже по няколко стойности с различен дизайн в различни области на сайта.
$ C = нови stdClass;
$ С-> INCPATH = dirname (__ __ FILE) "/" .;
CHDIR ($ С-> INCPATH);
Харесва ли ти тази актуализация DataLife Двигател 11.2?
Свързани статии