Эгея без реестра
На системном уровне в Эгее было сделано много важных изменений:
- Больше нет дебильного реестра!
- Разбор и генерацию урлов делает движок.
- Новая подсистема тем-шаблонов берёт вообще весь вывод в браузер на себя.
- Переписана подсистема кеширования и теперь она работает нормально.
Сначала про реестр. Раньше в E2 был файл registry.psa, в котором хранилось вообще всё, что движку нужно было хранить на сервере, в виде сериализованного ПХП-массива (PSA — это PHP Serialized Array). Ну, кроме того, для чего предназначена БД. Каркас движка был так устроен, что обработка любого запроса начиналась с чтения реестра и заканчивалась его записью. Я относился к нему как к постоянному хранилищу любых данных. Я мог просто написать где угодно $registry[’setttings’][’somesetting’] = some_value и знать, что это значение сохранится. В результате в реестре хранились всякие параметры, данные установщика, какая-то статистика, хеш пароля, какая-то отладочная фигня, кеш (!) и чёрт знает что ещё.
Иногда случалось страшное: файл реестра умирал. Видимо, в каких-то ситуациях получалось так, что движок не успевал его дописать и прекращал работу (хотя ignore_user_abort был полный). После этого целостность файла нарушалась и прочитать его назад уже было нереально. В какой-то из версий у меня даже появилась специальная чинилка реестра, которая пыталась хоть как-то восстановить что-то из нецелостного файла, но всё равно это спасало далеко не всегда. В результате движок не мог продолжать работу: он даже не знал, как соединиться с базой.
Возврат движка к рабочему состоянию был не очень сложным — для меня, который знал, как там что устроено, — но для пользователей это был коллапс. Просто вдруг всё переставало работать и было непонятно, что делать. Да, инсталлятор тогда не умел устанавливаться путём подключения к существующей базе, а не создания новой (в Эгее — умеет), поэтому даже неясно было, как переустановить движок, чтобы сохранить все заметки.
Сейчас такой лажи просто нет, потому что всё хранится в своём месте и записывается только когда нужно. Файл с пользовательскими параметрами пишется вообще только один раз при установке движка и далее только если кто-то решит их поменять. Поэтому вероятность того, что файл умрёт, стала на несколько порядков меньше. Но даже если это почему-то произойдёт, движку не придёт в голову переставать работать. Всё, что успело сохраниться в кеше, вообще продолжит показывать как ни в чём не бывало. А настройку подключения к базе можно будет повторить прямо через веб-интерфейс.
В результате всё стало радикально надёжнее и немножко быстрее. О других изменениях — в следующей серии.
С большим интересом читаю! Особенно хотелось бы прочесть про новую систему шаблонов.
Хорошо и логически правильно хранить параметры настройки в отдельной таблице базы данных. Поскольку эти параметры требуются часто, их нужно кешировать в отдельный php-файл.
Почему это правильно? Таким образом сокращается количество файлов, которые вместе с дампом базы данных образуют архив сайта. (В идеале архив должен состоять из одного дампа, но это правило нарушается, если пользователь может загружать свои файлы).
Я хочу воспользоваться случаем и попросить людей с «гуманитарным складом ума» никогда больше не писать код. Пожалуйста, пишите лучше книги, блоги, нажимайте друг другу лайк.
Только хорошее воспитание не позволяет мне ответить вам так, как следует отвечать на подобные комментарии.
Илья, проверь отдачу РСС, у меня в Опере (11.01) выдаётся ошибка «XML parsing failed», на <title>Эгея без*&*nbsp;реестра</title> (выделено). Чей баг, Эгеи, или Оперы?
Зореслав, а продемонстрируйте нам что-то из своего творчества, пожалуйста.