хапвам, значи съм!
Не, няма да разправям какво ядох снощи (макар че определено беше много добре). Пускам този пост за да известя, че след повече 4 месеца кибичене на домашната ми машина (не за друго, аз си наумих, че DOMXML библиотеката на PHP е надеждна и я има някъде!) хранително вкусовия блог на гусин Борислав Димитров най-накрая видя бял свят. Получи се малко и като импровизиран подарък за рожденния му ден
Откъм технология цялото нещо е един доста голям експеримент, крепи се на minixml библиотеката за php (прилично върви) + хипер изчанченa многослойна архитектура + малко заигравка с mod_rewrite (хехе, за първи път нацелих regexp-а от първия път!) + една темплейтна самоделка от един негов познат девелопер (доста практична и малка btw, ама доста по-назад от Smarty). И като добавиш xhtml/css въжделенията на баш готвача … стана направо да се чудиш как върви
Декември 30th, 2003 at 5:57 pm
Хехе, добър начин за комбинация на идеи
Блогът го има от доста време и никога не се бях замислял как работи (то и да мисля, едва ли щях да позная).Това ми напомня за времето, когато пишех собствен клас за темплейти
докато не пробвах Smarty… без коментар какво се случи по-нататък
Наскоро ми хрумна блестящата идея да направя скелет за всичките ми бъдещи проекти.Какво представлява този скелет? Значи, изграден е на модули, като има и ядро.Ядрото зарежда всички необходими модили за работата на “приложението” (скрипта), като модули за базата данни, member login, session, output, template и мн. други, които са все вътрешни модули.След това, зарежда външните модули (тоест, самият сайт вече), като определящото кой/кои модули ще се заредят е id-то на страницата.Всеки модул има достъп до вътр. модули и всичко е толкова лесно… Ето ви един пример:
Index.mod.php
class Index extends BaseModule {
function Index()
{
$this->BaseModule();
}
function act_Default()
{
global $app;
if (!$app->login->logged()) {
$app->tpl->display(’login.htm’);
} else {
$sql = “….”;
$app->db->query($sql);
if ($app->db->num_rows() < 1) {
$app->error($app->lang->get_text(’invalid_login’));
}
$user = $app->db->fetch_array();
}
}
function act_Login()
{
global $app;
if (($name = $app->input(’name’)) != NULL && ($pass = $app->input(’password’)) != NULL) {
if (!$app->login->member_login($user, $pass)) {….} else {…}
}
}
}
И тъй нататък
Декември 30th, 2003 at 7:04 pm
Уххх, много има да се говори по този въпрос, радвам се че има хора, интересуващи се от подобни неща.
За мен успешното разделение е следното - Data Access Layer (връзка и манипулация на data storage) - за което препоръчвам ADODB - много прекрасно. Отделно ако ти трябват различни технологично ориентирани модули (IMAP връзка, комуникация с сървъри други, CC процесори, тем подобни…), те също се обособяват като класове. Да не забравим централизирана система за прихващане и обработка на грешки.
След това идва логиката на приложението, “бизнес обектите”, извличаме техните свойства от схемите, начертани предварително, които илюстрират които сме начертали процеса на работата на приложението… те вътрешно в себе си употребяват data access и каквото там се наложи.
Накрая идва UI (User Interface), което вече се грижи изцяло за поемането на взаимодействието с потребителя. Добре е да се ползва template model, макар че Smarty ми е супер смотан, като го сравня с asp.net (еххх…) но определено е нещо.
Има много за говорене, но определно php е труден за имплементиране на такъв тип архитектура… Лека полека ще стигна и дотам. Но най важното е да не се впускаш в частни случаи, за това си има наследяване за конкретен проект
…
Декември 31st, 2003 at 12:00 am
Винаги най-голямият ми проблем е бил обработката на грешки.Така и не можах да напиша свестен механизъм, който да може да се справя отлично с този проблем.Но, за сметка на това имам малко идеи, но те са трудни за имплементация.Мисля си за множествено наследяване (BaseObject -> Object -> ErrorHandle -> ErrorReport -> Module), но става адски сложно
Друг проблем също е и самото разделяне на вътрешни и външни “модули” - малко объркващо, но няма как…
Определено изграждането на един общ “скелет” е добра идея, спестява доста труд и е лесно за ъпдейтване (просто се заменят файловете).
Мисля си, какво ще стане, ако примерно този “скелет” се хоства на дадено място и е базов за всички следващи проекти? Възможно ли е, как ти се струва тази идея? При една добра капсулация на данните няма да се налага ъпдейт на сайтовете, които ползват този “скелет” и ако има промяна, примерно в бързодействието, това ще се отразява навсякъде.
Стига толкова от мен, замечтах се вече, личи ми
) Поздрави и ВЕСЕЛИ ПРАЗНИЦИ НА ВСИЧКИ
Пожелавам ви никога повече спам
Декември 31st, 2003 at 1:26 pm
Мтъй… значи едно по едно. Обработката на грешки за мен трябва да предоставя следната функционалност:
- Поддръжка на debug и release състояние (в едната е ясно че бълва грешките директно в страницата)
- Бърз и лесен механизъм за уведомяване за инциденти (например най неангажиращото е изпращане по мейл, обаче ако сте 30 човека е добре като идея да репортва в някаква централизирана bug tracking система)
- Възможност за отбелязване на “проблеми” и “потенциални заплахи” при оперирането на системата (363 коментара за 1 минута например не е бъг, но трябва да бъде отразен).
Microsoft *заляга да не го пребият с камъни* са разработили exception management app block за .net -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/emab-rm.asp
според мен подходът им (макар и доста усложнен) е правилният. Архитектурата на този “блок” може да се опрости и изгради на php. Да не забравяме, че оттам нататък всички останали парчета от кода трябва да се съобразяват с наличието на този блок и да не обработват грешките “на парче”, също и да “хвърлят” грешки ако се наложи. (PHP справка - trigger_error). Предвид излизането на php 5 (където вече има try catch finally, ако не се лъжа разбира се) може да се очаква error handling историята да стане малко по-културна.
За общия скелет - да, идеята е добра. Предимно ако разполагаш със собствен сървър. Дори е заложено в php енджина - обща include директория, където сложените неща са достъпни навсякъде. Под .net си имаш GAC - global assembly cache, пак със подобна идея.
И за финал да подчертая дебело, че изграждането на такъв скелет никак, ама никак не е лесна работа. Оценявам го като “висш пилотаж” предвид леките проблеми при употребата на ОО PHP…
Декември 31st, 2003 at 1:29 pm
Ето и един kick старт за обработка на грешки -
http://underlog.org/full_story.php?NewsID=28
Не е кой знае какво, но за малки неща може да се употреби без всякакво замисляне