Перегрузка класса modX
В целях ускорения метода invokeEvent() возникла задача перегрузить класс modx.
Собственно, перегрузить класс и написать свой invokeEvent(), как оказалось, самая простая часть задачи. Сложнее выполнить подмену стандартного класса modX своим.
В исходных кодах объект modX создаётся в 4 местах:
1) При инициализации контекста «web»: в index.php
2) При инициализации контекста «mgr»: в connectors/index.php, manager/index.php и manager/min/index.php
Вариант 1. Вручную во все эти 4 файла в определённом месте подключается свой php-файл, в котором объявляется свой класс и создаётся объект этого класса. Вариант вполне работоспособен, но является неуниверсальным и некрасивым.
Вариант 2. Те же действия выполнить путём запуска некоторого скрипта от имени админа. Вариант небесопасен.
Вариант 3. Изменить файл modx.class.php:
а) имя класса «modX» заменить на любое другое (везде, где оно используется)
б) в конце файла подключить описание собственного класса с именем «modX», унаследовав стандартный класс
Вариант самый некрасивый.
Какие ещё варианты существуют? Задачу необходимо решить универсально и красиво.
Собственно, перегрузить класс и написать свой invokeEvent(), как оказалось, самая простая часть задачи. Сложнее выполнить подмену стандартного класса modX своим.
В исходных кодах объект modX создаётся в 4 местах:
1) При инициализации контекста «web»: в index.php
2) При инициализации контекста «mgr»: в connectors/index.php, manager/index.php и manager/min/index.php
Вариант 1. Вручную во все эти 4 файла в определённом месте подключается свой php-файл, в котором объявляется свой класс и создаётся объект этого класса. Вариант вполне работоспособен, но является неуниверсальным и некрасивым.
Вариант 2. Те же действия выполнить путём запуска некоторого скрипта от имени админа. Вариант небесопасен.
Вариант 3. Изменить файл modx.class.php:
а) имя класса «modX» заменить на любое другое (везде, где оно используется)
б) в конце файла подключить описание собственного класса с именем «modX», унаследовав стандартный класс
Вариант самый некрасивый.
Какие ещё варианты существуют? Задачу необходимо решить универсально и красиво.
Комментарии: 10
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Очень напоминает
позупозицию Запада в отношении России.1) Минус с первого поста на 2-й перенёс модератор, посчитав его необоснованным
2) За первый пост кто-то поставил плюс, компенсировав тем самым минус «Тайного поклонника»
Что же до озвученного вопроса — на мой взгляд, лезть в ядро и менять системные файлы — всегда некрасивое и не универсальное решение, так что первый вариант с доработкой напильником, имхо, самый верный.
Что касается вопроса изменения системных файлов и лучшего из предложенных вариантов — с вами полностью согласен — вариант 1 является наиболее корректным. А именно, в озвученных 4 файлах достаточно фрагмент
заменить на:
где smodx.class.php — файл с объявлением нашего класса smodX, наследующего стандартный класс modX.
И дело в шляпе…
2) Появляется возможность отслеживать время подключения классов, время инициализации, время выполнения запроса (modX::getRequest) и многих других операций, выполняемых modx, избавив себя от гаданий, почему modx «тормозит».
3) В момент инициализации modx (modX::initialize()) можно свободно подключать любые файлы (например, собственные библиотечные функции и классы), не обременяя себя строгой логикой пакетов. Эта возможность особенно актуальна, когда необходимо подключить все файлы из некоторой директории.
P.S. «Тайный поклонник» обязательно заминусует этот пост. Можно ставки делать ))
Причем можно реализовать два ядра — две папки core, одна обновляется, вторая нет — в ней собственный наследник от modX == возможность работать со стандартным modx и собственным, со своим парсером.
Вот такая мысль.
а) запросы на чистом pdo
б) отказ от объектов
в) г) д) — в invokeEvent не используется
Парсер Василия, вроде, так и работает (это если вдруг кто-то захочет заминусовать меня за «отказ» от объектов).