Перегрузка класса 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», унаследовав стандартный класс
Вариант самый некрасивый.

Какие ещё варианты существуют? Задачу необходимо решить универсально и красиво.
Cyrax_02
Cyrax_02
04 декабря 2014, 13:22
modx.pro
2 004
+1

Комментарии: 10

Cyrax_02
Cyrax_02
04 декабря 2014, 17:59
-4
Появился какой-то тайный поклонник, который меня неконструктивно минусует.
Очень напоминает позу позицию Запада в отношении России.
    Cyrax_02
    Cyrax_02
    04 декабря 2014, 18:06
    -3
    У первого поста минус исчез. Возможны 2 варианта:
    1) Минус с первого поста на 2-й перенёс модератор, посчитав его необоснованным
    2) За первый пост кто-то поставил плюс, компенсировав тем самым минус «Тайного поклонника»
      Максим Кузнецов
      Максим Кузнецов
      04 декабря 2014, 19:01
      0
      Без обид, я знаю, что ты хороший программист, судя по некоторым твоим постам и ответам, но зачем здесь о политике и паранойе?) Да и какая, в сущности, разница — сколько у твоих сообщений минусов и плюсов.

      Что же до озвученного вопроса — на мой взгляд, лезть в ядро и менять системные файлы — всегда некрасивое и не универсальное решение, так что первый вариант с доработкой напильником, имхо, самый верный.
        Cyrax_02
        Cyrax_02
        04 декабря 2014, 19:23
        0
        Суть не в количестве плюсов или минусов, а в отсутствии конструктива. Если бы я кому-то ставил минус (если бы и поставил), то предварительно обязательно бы конструктивно изложил свою позицию по вопросу. А пока эти минусы никак иначе охарактеризовать нельзя.

        Что касается вопроса изменения системных файлов и лучшего из предложенных вариантов — с вами полностью согласен — вариант 1 является наиболее корректным. А именно, в озвученных 4 файлах достаточно фрагмент
        $modx= new modX...
        заменить на:
        include dirname(dirname(MODX_CORE_PATH))).'/assets/smodx.class.php';
$modx= new smodX...
        где smodx.class.php — файл с объявлением нашего класса smodX, наследующего стандартный класс modX.

        И дело в шляпе…
    Алексей
    Алексей
    04 декабря 2014, 18:48
    0
    Какую задачу перед собой ставите?
      Cyrax_02
      Cyrax_02
      04 декабря 2014, 19:03
      +1
      1) Ускорение invokeEvent(). Этот метод выполняет код плагинов, повешенных на указанное событие, и реализует практически ту же логику, которая имеет место при обработке сниппетов (тот же самый modScript). Т.е. если возникает задача ускорения парсинга документа (собственный парсер), то логично заняться и ускорением метода invokeEvent(). Поскольку invokeEvent() — это та же самая обработка сниппетов, только код извлекается из плагинов.
      2) Появляется возможность отслеживать время подключения классов, время инициализации, время выполнения запроса (modX::getRequest) и многих других операций, выполняемых modx, избавив себя от гаданий, почему modx «тормозит».
      3) В момент инициализации modx (modX::initialize()) можно свободно подключать любые файлы (например, собственные библиотечные функции и классы), не обременяя себя строгой логикой пакетов. Эта возможность особенно актуальна, когда необходимо подключить все файлы из некоторой директории.

      P.S. «Тайный поклонник» обязательно заминусует этот пост. Можно ставки делать ))
        Алексей
        Алексей
        04 декабря 2014, 19:28
        0
        Я выбрал бы первый вариант

        Вариант 1. Вручную во все эти 4 файла в определённом месте подключается свой php-файл, в котором объявляется свой класс и создаётся объект этого класса. Вариант вполне работоспособен, но является неуниверсальным и некрасивым.
        Причем можно реализовать два ядра — две папки core, одна обновляется, вторая нет — в ней собственный наследник от modX == возможность работать со стандартным modx и собственным, со своим парсером.

        Вот такая мысль.
          Cyrax_02
          Cyrax_02
          04 декабря 2014, 20:05
          0
          Свой парсер я включаю/отключаю в настройках (как и всё остальное). А делать два core только из-за собственного modx'а, думаю, и не стоит. Поскольку там всего 4 файла, в каждом из которых в одном месте достаточно изменить modX на smodX и наоборот (чтобы вернуться к стандартному modX).
      Виталий Киреев
      Виталий Киреев
      04 декабря 2014, 20:17
      +1
      Вариант 4. Пулл реквест в репозиторий MODX на GitHub с улучшенным (?) invokeEvent.
        Cyrax_02
        Cyrax_02
        04 декабря 2014, 22:03
        0
        Улучшенный invokeEvent() выглядит приблизительно так же, как и улучшенный парсинг тегов:
        а) запросы на чистом pdo
        б) отказ от объектов
        в) г) д) — в invokeEvent не используется

        Парсер Василия, вроде, так и работает (это если вдруг кто-то захочет заминусовать меня за «отказ» от объектов).
        Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
        10