Новость • Уже работает!
Давно уже ничего не писалось в блоге, поэтому покажу кое-что, надеюсь, интересное.
Много времени и сил было потрачено на модернизацию модуля данных Data, разработан модуль разграничения прав (контроля доступа) Access и модуль аутентификации пользователей Auth. В данный момент прорабатывается модуль Page, задача которого — генерация «представления» данных в формате HTML. Вот тут-то уже можно посмотреть, что получается.
В процессе работы над модулем Page (переименован в Html), создана примитивная новостная лента, правда, пока без возможности что-то в неё добавлять через web интерфейс. Но всё же, на неё можно посмотреть (и потрогать исходники в SVN).
HTML-страницы генерируются блочным принципом: есть корневой блок, в него вставляются подчиненные и так далее… У каждого объекта данных имеется шаблон, сам объект не знает о нём, тем более шаблонов может быть несколько разных для одного объекта. Выбор шаблона осуществляется модулем Page по системному имени класса объекта и системному имени самого объекта (если оно есть). Так, например, для новостей шаблоном будет файл news.tpl.php (принцип схож с друпаловским). Если файла news.tpl.php нет, то будет осуществляться поиск файла content.tpl.php – т.е. учитывается наследование классов. Если у объекта есть системное имя, то можно сделать шаблон для конкретного объекта.
Блоки – это тоже объекты данных, для них точно также используются шаблоны. При создании страницы для отправке её клиенту сначала выбирается корневой блок, выполняется его отображение. При этом с учётом юрла или состояния (настроек) системы выбирается блок для отображения его в корневом блоке. Шаблон корневого блока – это html с пустым body. Блок, вложенный в корневой, вставляется в body и определяет своим шаблоном схему страницы, например «шапку», «колонки», «подвал» и др. Далее продолжается вставка объектов данных в области блока. По сути даже не важно, что вставляется – блок или не блок – всё работает однотипно, просто блоки непосредственно относятся к «представлению» в формате html.
Ладно, пока ещё не всё проработано, чтоб в деталях рассказывать, если кто в теме, кому интересно, могу отвечать на вопросы на форуме, от вас требуется только создание темы.
Логин: «vova» или «admin»
Пароль: «pvova» или «padmin»
209504733 - Владимир (автор)
Хорошая работа
Поздравляю!
Если есть желание пиши, можно поговорить о структуре CMS(и не только о твоей, а вообще).
Да, хотелось бы, только это сложно в форме написания статей, так как многое ещё не решено, постоянно возникают новые мысли, новые идеи, обновляются решения по уже вроде бы обдуманным вопросам. Поэтому сейчас все разговоры среди заинтересованных происходят по ICQ. Я поэтому и говорю, что необходима постановка конкретного вопроса, например «Как организовать независимое подключение модуля капчты для форм, чтоб ещё можно было указывать для каких форм её использовать…»
На форуме без проблем могу развернуть обсуждение любого вопроса по поводу разработки движка. Это должно быть интересным для любого разработчика (своей) cms. Совместными размышлениями можно прийти к интересным решениям.
Ха ха)) админ раздела то нет ещё…
Время обработки: 0.066 сек
Скоростью удивляетесь? Не время ещё, на оптимизацию пока глаза закрываю с целью реализации гибкости, а уж потом будет проще понять, от чего можно отказаться, где оптимизировать, где и как кэшировать.
Ого, целая секунда на проверку юзера и пароля уходит. Советую задуматься над оптимизацией пока не поздно
потому что sleep(1) делается
как временная защита от перебора. Надо наверно взять на вооружение метод висты — задержку по времени делать если количество попыток больше 3-4, а не игнорировать дальнейшие попытки и не тормозить первые. Потом и каптча ещё будет.
Привет.
Вообще, с идеей хранить описание данных/объектов в БД я уже сталкивался, мне показалось слишком заморочно это, что ли. Такие системы как правило получаются довольно сложными. Уж лучше я буду традиционные модели делать, как в Django, RoR и php-фреймворках
Идея с событиями (и создании объектов при обращении к нему таким образом) интересная.
Посмотрел демку, и число запросов (79
) на вывод главной страницы, советую сделать кеширование аттрибутов, или что там из БД выбирается, примерно так (надеюсь понятно), должно работать быстрее (но все равно не очень быстро думаю):
function getAttribute($attribute)
{
static $local_cache = array();
// 1 Ищем в кеше в массиве
if (!array_key_exists($attribute, $local_cache))
{
// 2 Ищем в кеше в памяти
if (!($value = apc_lookup($attribute/* тут например поиск значения в APC или Memcached, первое наверно лучше */)))
{
// 3 Ищем данные в БД
if (!($value = search_in_mysql($attribute)))
{
throw new Exception("Not Found: $attribute");
}
// сохраняем в кеш
apc_or_memcache__store($attribute, $value);
}
// Сохраняем в массив
$local_cache[$attrubute] = $value;
}
return $local_cache[$attribute];
}
Также может где-то можно за одно обращение к базе выбирать несколько рядов или объектов, если есть большая вероятность что они тоже понядобятся.
Или же, как альтернатива, возможно стоит при первом запуске загружать в мемкеш всю схему объектов из БД, все равно же понадобится?
Привет.
))
Число запросов сейчас не показатель работы системы)), уже неоднократно говорил, что не следует пока обращать внимание на производительность. Над ней работа ещё предстоит серьезная и будет она, когда уже всё образуется с гибкостью и не только на уровне работы с данными, также и во взаимодействии модулей и всего прочего. Главная цель проекта — создание супер гибкой cms
Да, сейчас нет «долгосрочного» кэширования данных, но частично работа с данными (объектами) оптимизирована, вы только представьте, сколько было бы запросов к бд, если при каждом обращении к свойствам объектов выполнялся доступ к бд. Предложение за раз грузить несколько объектов уже реализовано
Спасибо за коммент))
Уже работает! — не работает!