какая-то операция изменила базу

Я, наверное, не очень удачно использовал термин "кэш". Речь шла об очень коротко живущем кэше. Который существует только в течении обработки одного запроса (формирования одной страницы). И предназначен исключительно для защиты от повторных вызовов одних и тех же функций. (Функцию второй раз вызвать будет можно, но запрос при этом она выполнять не будет).

Но, чем больше я думаю на эту тему, тем больше вопросов возникает. В общем, уже сам сомневаюсь, что такое решение будет эффективным
Нужно будет поэкспериментировать.

Вообще же кэшировать запрос как таковой невозможно, по той простой причине, что в качестве ключа нельзя использовать sql. Потому что при одном и том же sql можно получить совсем разные данные, в случае если например какая-та операция изменила базу. Поэтому кэширование в таких вещах лучше не использовать вовсе.

Зато спокойно можно использовать кэш в разных функциях. Например вывод последних записей. Один запрос, результат в кэш. Ключ кэша явно определяется, так что проблем нет. У меня практически все сложные функции имеют подобное кэширование и именно по этому такое малое ресурсопотребление.

Да, и в отличие от WordPress результат не сохраняется в глобальном объекте. Просто нет надобности.

и он будет выполнен. Дважды

Почему бы не кэшировать результаты этих запросов? Т.е. при первом обращении к функции запрос выполняется как обычно, а его результат сохраняется в $MSO (или другом глобальном объекте, подойдет обычный массив), при повторном вызове функции будут возвращаться сохраненные данные, а запрос выполняться не будет.
Получится что-то вроде временного кэша в памяти, который существует только для одного запроса. Своеобразная "защита от дурака".
Примечание. Это не предложение изменить MaxsiteCMS, скорее просто мысли вслух. В большинстве случаев этот кэш использоваться не будет. А если включено обычное кэширование, то разговаривать вообще не о чем, функция будет вызвана только при обновлении кэша.

плагин к jQuery

Zen Garden не использует JS для дизайна

Насколько я понял, в MaxSite CMS объект $MSO вообще не заполняется данными из базы (при инициализации).

Верно. Он служит только для инициализации, где хранятся разные переменные под разные случаи. Ну вроде активированных плагинов, определенных сайдбаров, хуки, пути.

Что будет если два раза вызвать mso_get_pages?

В зависимости от входных параметров сформируется sql-запрос и он будет выполнен. Дважды.

Все равно разметка получится сложной. Например, если не использовать CSS3, то для создания закругленных уголков нужны вложенные div'ы для одного и того же блока.

Не совсем. Я все чаще использую плагин к jQuery - Cornerz, который работает с любым браузером и очень неплохо скругляет углы. Я его даже в комплект MaxSite CMS включил.

То есть получается двойная работа.

Да, не самый оптимальный вариант . Насколько я понял, в MaxSite CMS объект $MSO вообще не заполняется данными из базы (при инициализации).
Есть небольшой вопрос. Что будет если два раза вызвать mso_get_pages?

немного упростить задачу до каких-то типичных структур

Все равно разметка получится сложной. Например, если не использовать CSS3, то для создания закругленных уголков нужны вложенные div'ы для одного и того же блока. Такие нюансы придется учитывать, иначе количество чудес поубавится

Если я правильно понял, данные, которые возвращают функции с этой страницы http://codex.wordpress.org/Function_Reference движок получает заранее?

В WordPress есть такой глобавльный объект $wp_query, который вроде аналога $CI. И формируется он в момент инициализации системы. То есть вначале роутер смотрит текущий ЧПУ, потом его парсит и уже по нему пытается построить sql-запрос. И при этом сразу же его выполняет.

Таким образом $wp_query уже заполнен в момент передачи управления шаблону. Потом, если сделать query_posts, то это по сути заставит измениться $wp_query, путем парсинга и модификации последнего sql. То есть получается двойная работа.

Я просто фрагмент настроек привел только для одной темы. Т.е. можно сделать:

Вот как раз CMS и отличается от фреймворка тем, что в ней можно подключать любые файлы с помощью обычного require и уже в нем получать нужные данные для вывода.

Идеальный вариант. Очень высокие требования к разметке, но оно того стоит.

Если немного упростить задачу до каких-то типичных структур, вроде две колонки, текст, то все варианты спокойно уложатся в один html. А с помощью CSS, можно уже чудеса творить. Но, хотя, конечно же тут требуются хорошие знания CSS.

жесткие ограничения на файлы шаблона

Да, это основной недостаток. Но при этом разработчику шаблона не нужно изучать API. Для CMS, однозначно не подходит, но для небольших проектов с фиксированной структурой может иметь смысл.

для «фанатов» MVC просто не допустимо

Я не фанат . И, честно говоря, не знаю примеров CMS, которые сделаны в строгом соответствии с MVC.

Пример с WordPress не совсем некорректный

Да подробно разобраться с WP у меня руки не дошли . Если я правильно понял, данные, которые возвращают функции с этой страницы http://codex.wordpress.org/Function_Reference движок получает заранее?

фиксированных php-файлов во вьювере

Почему фиксированных? Их можно менять. Последний пример в конце статьи, когда имена файлов и их количество задаются в массиве отдельно для каждой темы. Я просто фрагмент настроек привел только для одной темы. Т.е. можно сделать:
$config['themes']['default']['page'] = array('header', 'content', 'sidebar', 'footer');

$config['themes']['classic']['page'] = array('header', 'content', 'footer');

зен гарден

Идеальный вариант. Очень высокие требования к разметке, но оно того стоит.

А вот с практической точки зрения здесь всё не так просто. Если контролер данные подготавливает всегда, то это накладывает очень жесткие ограничения на файлы шаблона. Данные которые они выводят также будут строго предопределены.

Я когда начинал делать свою MaxSite CMS, то столкнулся с подобной проблемой, и по этой причине ввел понятие типа данных. То есть в вашем примере, получая данные из базы, система определяет тип данных и по этому типу и выполняется подключение конкретного файла шаблона.

Но вообще такая поддержка шаблонов всё-таки тянет на CMS. CodeIgniter в исходном виде, да еще из-за своей MVC просто не имеет готовых решений. В частности получение данных обязательно должно переноситься во вьювер. (Как у меня.) Ну а это для «фанатов» MVC просто не допустимо.

Пример с WordPress не совсем некорректный. Я бы даже сказал, что все как раз наоборот: WordPress вначале получает данные (аналог контролера), а уже потом можно «перебить» их в шаблоне (аналог вьювер). (Если совсем строго, то можно сразу перехватить начальные запросы с помощью плагина и хука на init.) Именно из-за такой архитектуры WordPress столь ресурсоемкий и негибкий.

Да и еще. На мой взгляд именно такая схема шаблона не очень удачна. Просто из-за фиксированных php-файлов во вьювере теряется смысл шаблонов как таковых. Но, зато можно продумать эти файлы так, чтобы при одной html-разметке можно было бы подключать разные css-файлы. В этом случае достаточно только ввести один параметр - имя css, а разработка самого шаблона по сути сведется к css-верстке. Тогда можно не заботиться о программировании. Из подобных разработок могу упомянуть зен гарден. Да и у любого верстальщика в загашнике всегда есть свои аналогичные решения.