Пишу в данный момент для modx с использованием индивидуальных документов для каждого обычного пользователя.
Поскольку забивать этими документами админку не хотелось (если с сайтом все нормально будет, их там будет многовато и админка начнет тормозить), решил вынести их в отдельную таблицу БД, с выводом через один ресурс.
Итак, рассмотрим наши требования к документу (по крайне мере, у меня были такие):
У документа должны быть заголовок и содержание;
У документа должен быть тип (для более простого поиска документов одного типа);
У владельца документа всегда есть доступ к его редактированию и просмотру;
У владельца сайта и его юристов есть произвольный доступ к любому из документов;
Владелец сайта и те, кому он это разрешил, должны иметь возможность выдавать нужным им пользователям права на просмотр и редактирование произвольного документа;
Произвольный зарегистрированный пользователь может получить право на только просмотр либо также и редактирование произвольного документа на время либо сразу навсегда.
Данный топик наверняка будет полезен тем, у кого довольно большие проекты на MODx Revolution, так как с обычными сайтами-визитками достаточно и стандартных методов работы а-ля $modx->getObject(), $modx->getCollection() и т.п. И данные методы по сути своей не просто работа с базой данных, а еще и с объектами MODx.
При работе с большими проектами методы а-ля $modx->getCollection() для нас не лучшее решение по двум причинам:
1. Перерасход ресурсов. Данные методы не просто получают данные из БД, но еще и создают инстанции получаемых объектов. В данном случае получая информацию о 10000 документов, мы получаем 10000 объектов modResource, что не очень круто.
2. Осложняется задача подсчета получаемых записей. Помимо прямых сложностей подсчета еще на уровне запроса, даже если вы получите 10 записей одного и того же документа (к примеру), MODx вернет вам как результат только один объект modResource. И хотя часто такое устроит многих программистов (они получили уникальные объекты и рады), кого-то это не устроит, так как опять же происходит перерасход ресурсов, а по конечному результату сразу и не видно, что запрос не оптимизированный.
К тому же при работе на крупных проектах нам чаще всего нужны не сами объекты, а только информация (записи из базы данных).
Описанные здесь методы работы с БД ставят 2 задачи:
1. Дать бОльшую гибкость в написании запросов к БД.
2. Придерживаться стандартных методов xPDO, то есть избежать чистого SQL, так как чистый SQL по некоторым причинам в фреймворках вообще не кашерно (хотя бы с точки зрения возможной миграции на другой тип БД, смены названий таблиц, префиксов или еще чего-нибудь)
Хочу представить вашему вниманию свою разработку по быстрому выводу контента на сайтах MODX Revolution.
Как известно, эта система целиком построена на собственной ORM под названием xPDO. Она очень упрощает работу, позволяет писать один универсальный код для разных БД, и еще много чего.
К сожалению, она не может похвастаться скоростью вывода (как, наверное, вообще любая ORM), поэтому я попробовал совместить её плюсы с обычным PDO, добавить лучшую работу с чанками и сделать удобную библиотеку для MODX.
Основные особенности:
Быстрая работа с БД. Все запросы составляются на xPDO, а выбираются без объектов — на PDO.
Предварительная обработка простых плейсхолдеров в чанках. Парсер MODX разбирается только со сложными вызовами.
Код чанков можно указывать прямо при вызове сниппета, загружать обычным образом или из статичных файлов.
Правильная сортировка, подготовка, обработка и вывод ТВ параметров.
Ведение подробного журнала работы сниппета с отметками времени, для отладки.
Удобная загрузка классов и множество функций, которые можно применять в своих разработках.
В комплекте 8 универсальных сниппетов, которые дают хороший базис разработчику.
В настоящий момент занимаюсь переделкой одного новостного портала на MODX Revolution. Так как посещаемость на сайте бывает до 100 000 человек в сутки, вопрос производительности здесь один из самых важных. С учетом того, что на текущий момент в базе более 75 000 статей, при неправильном (и даже при традиционном подходе к разработке на MODX) тормоза сайта практически гарантированы, а если частота посещений превысит время выполнения запроса, то сервер вообще ляжет. Вот часть приемов задействованных здесь для решения этих проблем я и опишу в этой статье.
Совсем недавно Сергей Прохоров ака proxyfabio написал статью Валидация объектов + транзакции. Немного эта тема обсуждалась здесь. От себя хочу добавить, что эта тема крайне важная, и на сегодня это одна из самых главных проблем в разработке крупных проектов на MODX Revolution.
Здесь сразу попрошу не начинать ничего вроде «Если делаете крупные проекты, не надо их делать на MODX, возьмите бла-бла-бла». Мы делали крупные проекты, и не только на MODX. На MODX вполне можно делать крупные проекты, и на сегодня есть всего лишь пара слабых мест, которые мы правим на индивидуальных проектах, в остальном же MODX на 98% пригоден для разработки крупных проектов.
В данной статье мы разберем следующие вопросы:
